Teslimat onayı yalnızca bir sınırı doğrular
HTTP 2xx yanıtı, alıcı servisin isteği kabul ettiği, kuyruğa aldığı veya tamamen işlediği anlamına gelebilir. Bunlar farklı garantilerdir. Finansal iş akışı, olayın hangi noktada kalıcı hale geldiğini ve taşıma katmanının onayından sonra işleme başarısız olursa ne olacağını açıkça tanımlamalıdır.
Alıcı sistem mükerrer teslimata dayanıklı olmalı
Sağlayıcı onay alamazsa webhook'u yeniden gönderebilir. Alıcı sistem aynı olayın birden fazla kez gelebileceğini varsaymalı ve kalıcı olay kimliği veya ticari anahtar üzerinden idempotent işlem yapmalıdır. Mükerrer kayıt kontrolü süreç yeniden başladığında da korunmalıdır; yalnız bellekte tutulan kayıt yeterli değildir.
Olay sırası varsayılmamalı, modellenmeli
Dağıtık sistemlerde olaylar geç veya sıra dışı gelebilir. Ağ sırası ticari sıra kabul edilmemelidir. Kaynak sürümü, olay zamanı, durum geçişi veya mutabakat sorgusu; gelen olayın hâlâ uygulanabilir olup olmadığını belirlemelidir.
Kurtarma için webhook dışında bir doğrulama kaynağı gerekir
Olay kalıcı olarak kaybolursa veya alıcı sistem yanlış yapılandırılmışsa durumu yeniden kurmanın başka bir yolu olmalıdır. Periyodik mutabakat, sağlayıcı sorgu API'leri, yeniden oynatılabilir olay geçmişi veya geri doldurma uç noktaları bu kurtarma yolunu sağlar. Aksi halde güvenilirlik tek mesajın başarıyla gelmesine bağımlı kalır.
Teslimat, kabul ve işlemeyi ayrı aşamalar olarak tanımlayın
Sağlayıcının webhook göndermesi, ağ ucunun mesajı alması, uygulamanın kabul etmesi ve ticari işlemin başarıyla kaydedilmesi farklı aşamalardır. Sistem, 2xx yanıtının hangi sınırı onayladığını açıkça bilmelidir. Uç nokta kalıcı kayıt oluşmadan başarı dönerse bir çökme olayı kaybettirebilir ve sağlayıcının yeniden denemesi durmuş olur. Buna karşılık uzun bir sonraki iş akışını beklemek de gereksiz mükerrer teslimatlar yaratabilir.
Yaygın yaklaşım olayı doğrulamak, kalıcı biçimde kaydetmek veya kuyruğa almak, hızlı biçimde onay vermek ve asıl ticari işlemi bu kalıcı kayıttan yürütmektir. Uygulama biçimi değişebilir; ancak sınır bilinçli, gözlemlenebilir ve test edilebilir olmalıdır.
Teslimatı kırılgan hale getirmeden olayı doğrulayın
Webhook güvenliği çoğunlukla sağlayıcı imzası veya gizli anahtar doğrulaması, zaman damgası kontrolü ve taşıma güvenliğini içerir. Sağlayıcı ham gövde veya belirli bir kanonik biçim istiyorsa doğrulama bunu kullanmalıdır; JSON'u ayrıştırıp yeniden oluşturmak imzayı bozabilir. Anahtar rotasyonu ve saat farkları da operasyonel olarak ele alınmalıdır.
Güvenlik hataları uygulama hatalarından ayrı ölçülmelidir. İmza doğrulama hatalarında ani artış yanlış yapılandırma, anahtar rotasyonu problemi veya kötü niyetli trafik gösterebilir; hepsini genel 4xx hatası olarak görmek gerçek nedeni gizler.
Idempotency'yi ticari işlem sınırında tasarlayın
Sağlayıcı olay kimliğiyle mükerrer kayıt kontrolü aynı olayın tekrar teslim edilmesinin yan etkileri tekrarlamasını engeller; ancak farklı taşıma kimliği taşıyan anlamsal olarak aynı olayları her zaman yakalayamaz. Ticari sonuç önemliyse—örneğin faturayı ödendi işaretlemek veya iade kaydı yaratmak—iş kuralları ve durum geçişleri ikinci güvenlik katmanı olmalıdır.
Idempotent işleme; e-posta, muhasebe kaydı, stok değişikliği ve sonraki mesajlar gibi yan etkileri de kapsamalıdır. Veritabanını güvenli biçimde güncelleyip müşteriye iki bildirim gönderen işlemci operasyonel olarak idempotent sayılmaz.
Sıralamayı durum makinesi problemi olarak ele alın
Ağ, ilgili olayların işletmenin beklediği sırada geleceğini garanti etmez. Daha ileri bir durum önce gelebilir veya eski bir olay yenisi işlendikten sonra yeniden gönderilebilir. Alıcı sistem kaynak sürümü, zaman damgası, sıra bilgisi veya gerektiğinde sağlayıcıdan güncel okuma kullanarak durum geçişinin hâlâ geçerli olup olmadığını doğrulamalıdır.
Amaç tüm olayları küresel olarak yeniden sıralamak değildir. Amaç iş modelinin imkânsız bir eski duruma geri dönmesini engellemektir. Ödeme durum makinesi tekrarlanan ve geciken kanıtları nihai sonucu bozmadan tolere edebilmelidir.
Yeniden oynatma ve mutabakatı ilk günden kurun
Dağıtım hatası, süresi dolmuş kimlik bilgisi, yapılandırma hatası veya sağlayıcı olayı nedeniyle bazı canlı mesajların kaçacağını varsayın. Güvenli yeniden oynatma için yeterli olay geçmişi veya sağlayıcı referansı tutun. Teslimat anında alarm oluşmasa bile sessiz veri boşluklarını bulabilmek için önemli kaynakları sağlayıcıyla periyodik olarak mutabakata sokun.
Bu kurtarma tasarımı olay yönetimini de değiştirir. Operatör 'her webhook geldi mi?' yerine 'yerel finansal durumun doğru olduğu kanıtlanabiliyor mu; değilse hangi işlem grubunun yeniden oynatılması veya mutabakatı gerekiyor?' diye sorar. Bu daha güçlü bir güvenilirlik hedefidir.
Webhook onayının tam olarak neyi garanti ettiğini açıkça tanımla.
Olayları kalıcı kimlikle ve idempotent biçimde işle.
Geliş sırasını ticari işlem sırası olarak kabul etme.
Canlı teslimat dışında durumu yeniden kurabilecek bir kurtarma yolu koru.