WebhookBot ürünümüzü kurarken karşılaştığımız 8 problem ve nasıl çözdüğümüz.
Bu yazıda konuyu üretim deneyimimizden 5 maddeyle açıyoruz: hangi durumda hangi tercih kazanır, hangi tuzaklara dikkat etmek gerekir, ve 2026'da hâlâ yararlı olan kararlar nelerdir. Bizim 12 yılda 9 ürün yayınlarken karşılaştığımız gerçek senaryolar bu yazının kaynağı — pazarlama içeriği değil, mühendislik notu.
1. At-least-once teslimat — idempotency anahtarı
Stripe gibi sağlayıcılar aynı event'i 2-5 kez gönderebilir. events_processed tablosu, ilk satırınız olsun. event.id'yi UNIQUE constraint ile koruyun. Retry işin doğal parçası.
Bu noktayı bizim üretim ortamımızda nasıl uyguladığımızdan örnek: ilk projede kararı çabuk verdik ve sonra geri döndük. O günden beri her yeni projede aynı kontrolü 30 dakikada yapıyoruz; süreç bizi çok kazandırıyor.
2. Retry stratejisi — exponential backoff
1s, 5s, 30s, 5dk, 30dk, 2sa, 12sa. 24 saat sonunda dead-letter queue. WebhookBot'ta production'a aldığımız sıra: cron + Redis sorted set. Stripe'ın kendi standardı da benzer.
Bu noktayı bizim üretim ortamımızda nasıl uyguladığımızdan örnek: ilk projede planlamayı 2 hafta uzattık. Erken kararın geç bakım maliyeti her zaman daha düşük olduğunu öğrendik.
3. Ordering — sıra şart mı?
Çoğu webhook'ta evet. customer.subscription.updated'dan önce customer.subscription.created gelmeli. Queue + worker per-tenant şart; aksi halde abone aktif sayılmadan invoice geliyor.
Bu noktayı bizim üretim ortamımızda nasıl uyguladığımızdan örnek: ilk projede planlamayı 2 hafta uzattık. Erken kararın geç bakım maliyeti her zaman daha düşük olduğunu öğrendik.
- Hızlı kazanç: İlk hafta uygulayın
- Orta vade: 30 günlük sprint planına ekleyin
- Uzun vade: Çeyreklik metric'lerinizi yeniden tanımlayın
4. Signature doğrulama — HMAC-SHA256
Raw body üzerinde, JSON parse edilmeden önce. req.rawBody'yi middleware'den önce tutmazsanız Stripe doğrulama imkansız. Express body-parser tuzağı; bizim 3 müşterimizi ısırdı.
Bu noktayı bizim üretim ortamımızda nasıl uyguladığımızdan örnek: ilk projede planlamayı 2 hafta uzattık. Erken kararın geç bakım maliyeti her zaman daha düşük olduğunu öğrendik.
5. Observability — webhook health dashboard
Her tenant için failure rate, p99 latency, retry count. PagerDuty alarmları %5 üstü failure'da. Webhook'lar prod'da en sessiz şekilde kırılan altyapıdır; gözlem şart.
Bu noktayı bizim üretim ortamımızda nasıl uyguladığımızdan örnek: ilk projede planlamayı 2 hafta uzattık. Erken kararın geç bakım maliyeti her zaman daha düşük olduğunu öğrendik.
Sık sorulan sorular
Webhook mimarisi: retry, idempotency, ordering ne kadar sürer?
Senaryoya göre değişir; bizim uygulamalarımızda ilk değer 2-4 hafta, tam yapı 8-12 hafta. Bu yazıda detayları paylaştık.
Bu yaklaşımın bütçesi nedir?
Konuya göre değişiyor — ücretsiz ön görüşmemizde gerçek brief üzerinden tahmin veriyoruz.
Türkiye dışı projelerde de aynı tavsiyeler geçerli mi?
Genelde evet; sadece KVKK / vergi tarafları ülkeye göre değişir.