IHS Strategic
Tüm Blog Yazıları
HowTo20 Eylül 2026•4 dk okuma

Webhook Mimarisi ile Sistem Entegrasyonu Rehberi: Modern Web Uygulamalarında Adım Adım Entegrasyon

Modern web mimarilerinde sistemleri gerçek zamanlı bağlamanın en etkili yolu olan Webhook mimarisini adım adım kurun, güvenlik ve ölçeklenebilirlik dinamiklerini keşfedin.

S

Sistem Yöneticisi

Kıdemli Yazılım Mimarı

Giriş: Dijital Dönüşümde Gerçek Zamanlı İletişimin Rolü

Modern yazılım ekosistemlerinde verinin anlık olarak sistemler arasında taşınması, şirketlerin operasyonel hızını doğrudan belirler. Geleneksel yoklama (polling) mekanizmaları sunucu kaynaklarını tüketirken, olay odaklı (event-driven) mimarilerin yükselişi modern yazılım trendleri arasında en dikkat çeken başlıklardan biri haline gelmiştir. Bu rehber, web uygulamaları arasında asenkron, güvenli ve kesintisiz bir veri akışı kurmanızı sağlayacak webhook mimarisini sıfırdan prodüksiyona hazır hale getirecek adımları içermektedir.

Webhook, bir web uygulamasında belirli bir olay gerçekleştiğinde (event), önceden tanımlanmış bir hedef URL'e otomatik olarak HTTP POST isteği gönderen kullanıcı tanımlı bir geri çağırma (callback) mekanizmasıdır.

Neden Webhook? Polling ve Webhook Karşılaştırması

Bir e-ticaret sisteminde ödeme tamamlandığında faturanın kesilmesi veya kargo bildiriminin gönderilmesi gibi kritik iş süreçlerinde iki temel iletişim yöntemi bulunur:

  • API Polling (Yoklama): İstemci, belirli aralıklarla (örneğin her 5 saniyede bir) sunucuya istek atarak "Yeni bir durum var mı?" diye sorar. Bu yöntem, isteklerin %98'inde boş yanıt dönmesine ve gereksiz ağ/sunucu yüküne neden olur.
  • Webhook (Ters API): İstemci sunucuyu sürekli sorgulamaz; bunun yerine sunucu, olay meydana geldiği anda istemcinin belirlediği uç noktaya (endpoint) veriyi fırlatır. Bu, anlık tepki süresi ve minimum kaynak tüketimi sağlar.

Adım Adım Webhook Mimarisi Kurulumu

Adım 1: Olayların (Events) ve Payload Formatının Tanımlanması

Başarılı bir mimarinin temeli, net bir veri şeması oluşturmaktır. Olay isimleri tutarlı ve standart olmalıdır (örn. order.created, payment.succeeded, user.deleted).

Gereksiz büyük veriler yerine standart bir payload gövdesi tasarlayın:

{
  "id": "evt_987654321",
  "event": "payment.succeeded",
  "created_at": 1715000000,
  "data": {
    "payment_id": "pay_123",
    "amount": 450.00,
    "currency": "TRY",
    "customer_id": "cus_456"
  }
}

Adım 2: Webhook Endpoint (Alıcı/Consumer) Geliştirme

Alıcı sistem, gelen HTTP POST isteklerini karşılamak üzere güvenli bir REST uç noktası barındırmalıdır. Bu aşamada dikkat edilmesi gereken en kritik husus, gelen isteğe hızlı bir şekilde HTTP 200 OK dönmektir. Ağır iş mantıkları (e-posta gönderme, veritabanı eşitleme vb.) asenkron olarak arka plana devredilmelidir.

  • İstek gövdesini (raw payload) alın.
  • HMAC imzasını doğrulayın.
  • Hemen HTTP 200 OK yanıtı verin.
  • İşlemi bir kuyruk (queue) sistemine (RabbitMQ, Redis, AWS SQS) aktarın.

Adım 3: Güvenlik Katmanı ve HMAC Doğrulaması

Webhook alıcıları internete açık uç noktalardır. Yetkisiz istekleri engellemek için paylaşılan bir gizli anahtar (Secret Key) üzerinden HMAC SHA-256 imza doğrulaması uygulanmalıdır.

Gönderici taraf, payload'ı gizli anahtarla şifreleyerek X-Webhook-Signature başlığı ile gönderir. Alıcı taraf, aynı işlemi kendi tarafında tekrarlayarak hash değerlerini karşılaştırır (timing-safe comparison kullanarak timing attack risklerini önleyin).

Adım 4: Tekrarlayan İstek Yönetimi (Idempotency)

Ağ kesintileri veya timeout durumlarında gönderici sistem aynı webhook'u tekrar tetikleyebilir. Mimarinin, aynı bildirimi iki kez işlemesini önlemek için her webhook isteğine benzersiz bir event_id atanmalı ve işlenen ID'ler bir önbellekte (Redis vb.) tutularak tekrar eden işlemler filtrelenmelidir.

Adım 5: Yeniden Deneme (Retry) Politikaları ve Dead Letter Queue

Hedef sunucu geçici olarak çöktüğünde veya 5xx hataları döndüğünde, gönderici sistem Exponential Backoff (Üstel Geri Çekilme) algoritmasıyla yeniden deneme yapmalıdır (örneğin 1 dk, 5 dk, 30 dk sonra tekrar deneme). Belirli bir sınır aşıldığında istekler manuel inceleme için Dead Letter Queue (DLQ) havuzuna alınmalıdır.

Kurumsal Dijital Strateji Açısından Webhook Trendleri

Günümüz kurumsal mimarilerinde SaaS çözümleri (CRM, ERP, ödeme altyapıları) monolitik yapıların yerini almıştır. Doğru kurgulanmış bir dijital strateji, bu farklı servisleri gevşek bağlı (loosely-coupled) bir ekosistemde bir araya getirmeyi hedefler. Son yıllardaki teknolojik trendler incelendiğinde, Webhook sistemlerinin Kafka ve Serverless (AWS Lambda, Cloudflare Workers) mimarileriyle birleşerek mikroservis iletişiminin ana omurgası haline geldiği görülmektedir.

En İyi Uygulamalar (Best Practices) Kontrol Listesi

  • Hızlı Yanıt Süresi: Webhook işleyicinizin 500 ms'den daha kısa sürede 200 OK döndüğünden emin olun.
  • IP Beyaz Listesi (Allowlisting): Mümkünse gönderici IP adreslerini güvenlik duvarı seviyesinde filtreleyin.
  • İmza Doğrulama: Ham istek gövdesini parse etmeden önce HMAC imzasını doğrulayın.
  • Idempotent İşleme: Aynı bildirimin çoklu gönderimlerine karşı güvenli mimari kurun.
  • İzleme ve Loglama (Observability): Gecikme sürelerini, hata kodlarını ve yeniden deneme oranlarını merkezi bir log sisteminde (Datadog, Grafana) takip edin.

Sonuç

Webhook mimarisi, modern web ekosisteminde gerçek zamanlı entegrasyon kurmanın en standart ve verimli yoludur. Güvenlik, hata toleransı ve kuyruk sistemleriyle desteklendiğinde, webhook altyapınız yüksek hacimli veri trafiğini sorunsuz bir şekilde yöneterek sistemleriniz arasındaki iletişimi kusursuz hale getirir.