Webhook tekrar geldiğinde işlemi iki kez yapmamak

Örnek bir iş senaryosu

Bir sipariş bildiriminin alındığını, kaydın oluşturulduğunu fakat yanıtın göndericiye ulaşmadığını düşünün. Tekrar gelen bildirim yeni sipariş gibi işlenirse stok iki kez düşer. Kaynağın olay kimliği veya uygun bir işlem anahtarı kalıcı tutulmalıdır. Tekrar kontrolü ile iş kaydının oluşturulması aynı güvenilir işlem sınırı içinde yapılmalıdır.

Dört adımda çalışma düzeni

İlk bakışta görünmeyen noktalar

Olayların geliş sırasının da değişebileceğini hesaba katın. “Tamamlandı” olayı önce, daha eski “hazırlanıyor” olayı sonra gelebilir. Sadece son gelen bildirimi doğru kabul etmek kaydı geriye götürebilir. Kaynağın sürüm, zaman veya durum geçiş kuralları incelenmeli; geçersiz geriye dönüşler kontrol edilmelidir. Ağdan gelen zaman damgasına tek başına güvenmek de her sistemde yeterli olmayabilir. Olay işleme günlüğü, alınma zamanı ile kaynak olay zamanını ayrı tutmalıdır. Hata halinde destek ekibi hangi olayın neden reddedildiğini görebilmelidir. Ham yük saklanacaksa hassas alanlar ve saklama süresi ayrıca değerlendirilmelidir.

Bağlantıyı zor koşullarda doğrulama

Entegrasyon denemesine başarılı tek bir kayıtla başlayın, ardından kontrollü olarak hata koşulları ekleyin. Eksik zorunlu alan, bilinmeyen ürün kimliği, aynı olayın tekrarı ve geçici bağlantı kesintisi iyi örneklerdir. Her senaryoda beklenen sonucu önceden yazın. Hangi kayıt tekrar denenecek, hangisi insan incelemesine düşecek ve hangisi reddedilecek açık olmalıdır. İşlem günlüğünde kaynak kimlik ile hedef kayıt arasında bağlantı bulunmalıdır. Böylece sorun araştırılırken farklı sistemlerde aynı işin peşinden gidilebilir. Test anahtarları ve üretim anahtarları birbirinden ayrı tutulmalıdır.

Yeniden deneme politikasını dış servisin kurallarıyla uyumlu tasarlayın. Her hatayı aynı hızla tekrar göndermek kota sınırına takılabilir ve diğer işlerin de gecikmesine neden olabilir. Geçici bağlantı hatasıyla kalıcı veri hatası farklı davranış gerektirir. Kuyruğun en eski kaydı ve toplam bekleyen iş sayısı birlikte izlenmelidir. Az sayıda çok eski kayıt sessiz bir soruna işaret edebilir. Başarılı kaydın tekrar işlenmemesi kadar yarım kalan işlemin güvenli devamı da önemlidir. Bu nedenle işlem durumları yalnızca başarılı ve başarısız ikilisinden daha ayrıntılı olabilir.

İş birimi için okunabilir bir hata ekranı hazırlayın. Teknik hata kodunun yanında etkilenen kayıt, yapılabilecek işlem ve sorumlu ekip yer alsın. API sırları, parolalar ve gereksiz kişisel bilgiler günlüklerde bulunmamalıdır. Saklanan teknik kayıtların erişimi ve süresi belirlenmelidir. Canlıya geçmeden önce bağlantı kesildiğinde işin nasıl sürdürüleceğini de konuşun. Manuel işlem gerekiyorsa daha sonra senkronizasyon sırasında mükerrer oluşmaması için bu kayıtların işaretlenmesi gerekir. Başarı ölçütü yalnızca isteklerin yanıt alması değil, hedef işin doğru ve bir kez tamamlanmasıdır.

Ekibinize sorabileceğiniz sorular

• Aynı bildirim iki kez gönderilince ne oluyor?
• İmzası geçersiz olay reddediliyor mu?
• Yarım kalan işlem devam ettirilebiliyor mu?

Bu soruları seçtiğiniz örnek kayıt üzerinde yanıtlayın. Her açık nokta için sorumlu kişiyi, yapılacak düzeltmeyi ve yeniden kontrol tarihini not edin. Böylece görüşme, uygulanabilir bir iş listesiyle tamamlanır.