Başarısız bir otomasyonu yeniden çalıştırmadan önce, önceki denemede hangi adımların gerçekten tamamlandığını bilmek gerekir. Bir zaman aşımı, karşı sistemin hiçbir işlem yapmadığı anlamına gelmeyebilir. Aynı işi baştan başlatmak ikinci kayıt, ikinci mesaj veya tekrarlanan başka bir etki oluşturabilir.
Bu rehber sipariş ve operasyon akışları için tekrar çalıştırma tasarımı önerir. Belirli bir sağlayıcının bütün işlemlerinin aynı davranışı gösterdiği varsayılmaz. Her bağlantının kendi hata, tekrar ve kimlik kuralları doğrulanmalıdır.
İşin kimliğini denemeden ayırmak
Bir işin sabit kimliği, o işi gerçekleştirmek için yapılan denemelerin kimliğinden ayrılır. “Sipariş için takip bildirimi hazırlamak” bir iş olabilir; ilk ve ikinci deneme bu işin farklı yürütmeleridir. Deneme değiştiğinde işin kendisi yeni bir müşteri eylemi gibi yaratılmamalıdır.
İş kaydında bekleyen, sürmekte olan, tamamlanan, başarısız ve sonucu belirsiz durumları ayırırım. Sonucu belirsiz bir adım, doğrudan başarısız kabul edilip yeniden gönderilmez. Önce karşı sistemde işlemin gerçekleşip gerçekleşmediği araştırılır.
Yan etkileri adımlara bölmek
| Adım türü | Tekrar yaklaşımı |
|---|---|
| Veri okuma | Güncellik ve erişim sınırı korunarak yeniden denenebilir |
| Taslak hesaplama | Aynı girdinin sürümüyle tekrar üretilebilir |
| Dış kayıt oluşturma | Tekil iş kimliği veya sağlayıcının idempotency düzeni gerekir |
| Mesaj gönderme | Gönderim durumu ve tekrar engeli kontrol edilir |
| Para veya stok etkisi | Ayrı doğrulama ve yetki sınırı gerekir |
Her adım tamamlandığında kanıtı kaydedilir. Yalnız son satırda “iş bitti” yazan bir akış, ortadaki kısmi başarıyı anlayamaz. Yeniden çalıştırma, tamamlanmış adımları gerektiği gibi tanıyabilmelidir.
Idempotency’yi doğru kapsamda kullanmak
Idempotency, aynı mantıksal isteğin tekrarıyla aynı etkinin gereksiz yere yeniden oluşmasını önlemeye yardımcı olur. Örneğin Stripe, uygun isteklerde idempotency anahtarıyla güvenli tekrar mekanizması sunar; aynı anahtara ait sonucu saklar ve parametre uyuşmazlığını kontrol eder. Stripe resmi belgesi bunun sağlayıcıya özgü koşullarını açıklar.
Bu mekanizmayı bütün sistemler için sınırsız garanti gibi yorumlamam. Anahtarın saklama süresi, işlem kapsamı ve eşzamanlı denemeler önemlidir. Uygulamanın kendi iş kaydı ve mutabakat kontrolü yine gereklidir. Yeni deneme için rastgele yeni anahtar üretmek, aynı işlemi tekrar engelleme amacını bozabilir.
Hata türüne göre davranmak
Geçici bağlantı hatası, geçersiz veri ve yetki hatası aynı şekilde tekrar edilmez. Geçersiz bir ürün kimliğini yüz kez göndermek sorunu çözmez. Deneme sayısı ve bekleme aralığı sınırlandırılır; devam edilemeyen işler görünür bir inceleme kuyruğuna alınır.
Toplu işte tek kayıt sorunlu diye bütün başarılı kayıtlar baştan yürütülmemelidir. Kayıt düzeyinde sonuç ve hata nedeni tutulur. Bununla birlikte kayıtlar arasında iş bağımlılığı varsa kısmi tamamlanmanın anlamı açıkça tanımlanmalıdır.
Yeniden çalıştırmayı test etmek
Testler yalnız normal başarıyı kapsamaz. Dış işlem tamamlandıktan hemen sonra yanıtın kaybolması, işlem ortasında uygulamanın kapanması ve aynı işin iki kez başlatılması gibi senaryolar sınanır. Beklenen sonuç, tekrar denemenin açıklanabilir ve kontrol edilebilir olmasıdır.
Sipariş agent’ının yetki sınırları hangi eylemlerin ayrıca insan kontrolü gerektirdiğini; otomasyon mu AI agent mı? ise belirsizliğin hangi katmanda ele alınacağını tamamlıyor. İyi tekrar tasarımı, hatayı görünmez kılmaz; kısmi sonucun kaybolmasını ve aynı etkinin istemeden çoğalmasını önler.