Webhook kaybetmemenin mühendisliği: kuyruk, retry, idempotency

Ödeme gateway'leri (Stripe, Hotmart, Kiwify gibi) ile entegre olan her sistem er ya da geç aynı soruna çarpar: webhook alındı ama işlenmedi, ya da iki kez işlendi. Kaynak metin, saf bir webhook handler'ın neden dağıtık sistemler probleminin klasik bir örneği olduğunu adım adım açıklıyor. Senkron işleme (al-doğrula-işle-yanıtla) gateway'in timeout süresini aşınca gönderen taraf 'başarısız' der, alıcı taraf ise işlemi tamamlamış olabilir; bu belirsizlik veri kaybına yol açar.

Çözüm önerisi katmanlı: önce alım (ingestion) ile işlemeyi ayırmak, ham payload'ı kaydedip anında 2xx dönmek ve gerçek işi arka planda bir worker'a bırakmak. Bu, bir kuyruk yapısı gerektirir ve kuyruk beraberinde tekrarlanan teslimat riskini getirir. Bu yüzden her olay için stabil bir idempotency key (teslimat denemesinin değil, kaynağın kimliği) kullanılmalı; veritabanında UNIQUE kısıtı ile mükerrer işlemler engellenmeli.

Hedef sisteme teslim tarafında ise ters problem var: hedef çökebilir. Anlık ve döngüsel retry yerine exponential backoff (1dk, 5dk, 15dk, 1sa gibi artan aralıklar) ve N denemeden sonra Dead Letter Queue'ya düşürme öneriliyor. Ayrıca gelen/giden payload ve yanıtların loglanması, hem teşhis hem de toplu replay için gerekli görülüyor. Son olarak sistem, Black Friday gibi ani yük artışlarında da ayakta kalabilmeli; bu da alım katmanının hafif tutulmasını ve kuyruğun biriktirme kapasitesini zorunlu kılıyor. Yazar, bu prensipleri uygulayan HookSafe adlı bir aracı early access aşamasında geliştirdiğini belirtiyor.