Kararın dayanağı
Bildirimin gelmesi iş eyleminin bitmesi değildir. Tekrarı ve farklı sırayı düşünerek tasarlayın. Stripe kendi servisi için bunları belgeler; diğer sağlayıcının sözleşmesini ayrıca kontrol edin.
Somut bir örnek
Varsayımsal “fatura ödendi” olayı doğrulansın, kimliği ve planlanan iş kaydedilsin, kalıcı kabulden sonra yanıt verilsin. Tekrar gelince tanınarak ikinci alacak kaydı oluşmasın. Daha sonraki bir adım başarısız olursa işlem durumu korunsun ve eksik adım güvenle yeniden denenebilsin.
Değerlendirilecek seçenekler
Inbox yaklaşımı gelen olayı, outbox ise uygulamanızdaki veritabanı işleminden doğan dış işi kaydeder. Böylece yapılacak işin kalıcı kaydı, ağ üzerinden gönderimden ayrı tutulur. Mutabakat da herhangi bir hata bildirimi gelmese bile kaynaklar arasındaki farkı bulmaya yardımcı olur.
Planın aksadığı yer
Kimlikleri yalnız süreç belleğinde tutmayın, değişiklik commit olmadan tamamlandı demeyin. Eski olayı durum veya sürümle ele alın. Geçici hataya aralık verin, geçersiz veriyi incelemeye ayırın.
Teslim kimliği ile iş kimliğini ayırın
Fatura örneğinde sağlayıcının olay kimliğini ve fatura referansını birlikte tutun. Farklı olaylar aynı faturayla ilgili olabilir; faturayı bir kez gördünüz diye sonrakileri engellemek geçerli değişiklikleri kaybettirir. Aynı olayın tekrarı da aynı alacağı ikinci kez işlememeli. Alımı koruyan kimlikle iş durumunu koruyan kuralı belirleyip kontrolleri asıl değişiklikle birlikte commit edin.
İşi kabul etmeden göndericiyi sağlayıcının belgelenmiş yöntemiyle doğrulayın. Ham gövdeyi imzalayan servislerde JSON’u yeniden üretmek yerine alınan baytları koruyun. İmza secret’ını loga veya repository’ye koymayın. Doğrulama, retry zamanları ve olay saklama şartları seçilen sağlayıcıya aittir; başka servisten kopyalanan kod çalışır görünürken yanlış şeyi kontrol edebilir.
İşlem yarıda kesildiğinde nasıl devam edileceğini gösterin
Worker’ı olay alındıktan, kalıcı kabulden sonra ve iş değişikliği sırasında durdurun. Restart sonrası inbox ve iş kaydını birlikte inceleyin. Dış etki varsa uzak sistem yerel sonuç yazılmadan kabul etmiş olabilir. Desteklenen idempotency veya mutabakat sorgusu kullanın; yerel durum bayrağı tek başına exactly-once garantisi değildir.
Operatörün kontrollü retry işlemi eski olay kimliğini koruyup gerekçesini yazmalı. Kalıcı geçersiz veri sonsuz retry yerine istisna yoluna gitmeli. Mutabakat belirli aralıkta yetkili kayıtları karşılaştırıp açık farkları raporlamalı. Raporu kimin okuyacağını, acil farkın nasıl ele alınacağını ve olayın hangi kanıtla kapanacağını kararlaştırın. Sahipsiz kuyruk veriyi korurken işletmenin durduğunu kimse fark etmeyebilir.
İşe başlamadan önce
Tekrar tek etki bırakıyor mu? Worker çökünce devam edebiliyor mu? Bir kayıt araştırılıp güvenle yineleniyor mu? Entegrasyon kabulünde bunları gösterin.