Hızlı Özet (TL;DR)
Webhook; bir sistemde gerçekleşen bir olayın (ödeme alındı, fatura kesildi, üretim emri tamamlandı) diğer sisteme HTTP POST isteğiyle gerçek zamanlı iletilmesini sağlayan “ters API” mimarisidir. Sürekli polling (sorgulama) yapma ihtiyacını ortadan kaldırır. Ancak güvenilir bir webhook altyapısı kurmak; HMAC SHA256 ile imza doğrulama, hedef sunucu kapalıyken Exponential Backoff ile yeniden deneme (Retry) ve mükerrer kayıtları önleyen Idempotency mimarisini zorunlu kılar.
Webhook ve Polling Karşılaştırması
İki kurumsal sistem arasındaki veri senkronizasyonunda webhook ve polling farkları:
| Kriter | Geleneksel Polling (Her 5 Dakikada Bir Sor) | Webhook Mimarisi (Olay Tabanlı Bildir) |
|---|---|---|
| Gecikme Süresi | Ortalama 2.5 dakika (Bir sonraki sorguyu bekler) | 50 – 200 Milisaniye (Anlık tetikleme) |
| Ağ ve Sunucu Yükü | %99’u boş dönen milyonlarca gereksiz HTTP isteği | Yalnızca veri değiştiğinde tek bir HTTP çağrısı |
| Ölçeklenebilirlik | Kullanıcı arttıkça veritabanı sorgu kuyruğu tıkanır | Asenkron mesaj kuyruklarıyla (RabbitMQ) kolayca ölçeklenir |
| Hata Toleransı | Bir sonraki periyotta telafi edilebilir | Hedef sunucu çökmüşse yeniden deneme stratejisi şarttır |
Güvenlik: HMAC SHA256 İmzası ile Doğrulama
Webhook alıcıları gelen isteğin gerçekten beklenen kaynaktan geldiğini doğrulamalıdır. Gönderici sistem istek gövdesini gizli bir anahtarla (Secret Key) HMAC-SHA256 kullanarak imzalar ve X-Webhook-Signature başlığında iletir:
// Gönderici tarafında imza üretimi
const crypto = require('crypto');
const signature = crypto
.createHmac('sha256', secretKey)
.update(JSON.stringify(payload))
.digest('hex');
Alıcı sunucu aynı algoritmayla kendi imzasını hesaplar ve gelen başlıkla karşılaştırır. Eşleşmiyorsa istek doğrudan 401/403 ile reddedilir.
Exponential Backoff ile Yeniden Deneme (Retry)
Hedef sunucu geçici olarak çevrimdışı olduğunda istekleri saniyede yüzlerce kez tekrar göndermek hedefi tamamen kilitleyebilir. Bunun yerine katlanarak artan gecikme aralıkları (Exponential Backoff) uygulanır:
- 1. Deneme: Hata anında (0. saniye)
- 2. Deneme: 1 dakika sonra
- 3. Deneme: 5 dakika sonra
- 4. Deneme: 30 dakika sonra
- 5. Deneme: 2 saat sonra
Başarısız kalan istekler nihayetinde bir Ölü Mektup Kuyruğuna (Dead Letter Queue - DLQ) yönlendirilerek geliştirici ekiplerine bildirim gönderilir.
Kurumsal sistemler arası gerçek zamanlı webhook ve API entegrasyonları kurmak için Özel Yazılım Geliştirme sayfamızı inceleyebilirsiniz.