Webhook Nedir ve Neden Standart Polling Tercih Edilmez?

Modern web mimarilerinde sistemlerin birbiriyle haberleşmesi için geleneksel yöntem olan polling (periyodik sorgulama), gereksiz sunucu kaynağı ve ağ trafiği tüketir. Webhook mimarisi ise ters API (Reverse API) yaklaşımıyla çalışır; kaynak sistemde bir olay gerçekleştiğinde hedef sisteme anında HTTP POST isteği gönderilir. Bir dijital ajans ölçeğindeki karmaşık entegrasyonlarda ve mikroservis yapılarında gerçek zamanlı veri aktarımı sağlamanın endüstri standardı yöntemidir.

Webhook: İstemcinin sunucuyu sorması yerine, sunucunun olay anında istemciyi tetiklemesidir.

Adım 1: Güvenli Webhook Alıcı (Consumer) Uç Noktası Tasarımı

Bir webhook alıcısı oluştururken en kritik kural, gelen isteği anında işlemek yerine asenkron kuyruğa aktarmaktır. HTTP isteğini bekletmek, gönderici sistemin zaman aşımına (timeout) düşmesine neden olur.

200 OK Yanıtını Erken Dönün: Yükü (payload) doğrulayın, mesaj kuyruğuna (Redis, RabbitMQ vb.) yazın ve derhal HTTP 200/202 dönün.
İstek Gövdesi (Raw Body): İmza doğrulaması için JSON parse edilmemiş ham gövde verisini saklayın.

Adım 2: Güvenlik ve İmza Doğrulama (HMAC SHA-256)

Herkese açık bir endpoint dışarıdan sahte isteklere açıktır. Gönderici sistem, payload verisini paylaşılan bir gizli anahtar (secret key) ile hashleyerek HTTP başlığında (örneğin X-Hub-Signature-256) gönderir.

Doğrulama Adımları

Gönderilen ham veriyi gizli anahtar ile HMAC SHA-256 algoritmasından geçirin.
Üretilen hash ile gelen başlık değerini timing-safe (zamanlama saldırılarına karşı korumalı) karşılaştırma fonksiyonuyla eşleştirin.

Adım 3: Idempotency (Tekrarlayan İstekleri Önleme)

Ağ kesintileri nedeniyle gönderici aynı olayı birden fazla kez iletebilir (At-Least-Once Delivery). Sistemin aynı işlemi mükerrer yapmaması için Idempotency mekanizması zorunludur.

Her webhook yükünde bulunan benzersiz event_id değerini kontrol edin.
İşlenen olay kimliklerini TTL süresi tanımlı bir veri tabanında (örneğin Redis) saklayın.
Daha önce kaydedilmiş event_id gelirse işlemi tekrar etmeden HTTP 200 yanıtı dönün.

Adım 4: Hata Yönetimi, Exponential Backoff ve DLQ

Modern web trendleri, hata toleranslı sistem tasarımlarını önceler. Alıcı taraf 5xx hatası verdiğinde veya ağ koptuğunda gönderici yeniden deneme (retry) politikası uygulamalıdır.

Exponential Backoff: Denemeler arasındaki süreyi katlayarak artırın (1s, 5s, 25s, 2m, 10m).
Dead Letter Queue (DLQ): Maksimum yeniden deneme sınırına ulaşan başarısız paketleri inceleme amacıyla DLQ havuzuna aktarın.

Webhook Mimarisi İçin En İyi Pratikler

HTTPS Zorunluluğu: Taşıma katmanında verinin şifrelenmesi için SSL/TLS zorunlu tutulmalıdır.
Zaman Damgası (Timestamp) Kontrolü: Replay (tekrar) saldırılarını engellemek için istek başlığındaki zaman damgasını kontrol edin; 5 dakikadan eski istekleri reddedin.
İzleme ve Loglama: Her webhook çağrısının durum kodunu, yanıt süresini ve correlation ID değerini merkezi loglama sistemine kaydedin.