Pazaryerinde Webhook ve Event-Driven Mimari: 2026'da Gerçek Zamanlı Otomasyon ve Entegrasyon Rehberi

Bir pazaryeri platformunda her saniye onlarca olay gerçekleşir: yeni sipariş düşer, satıcı stok günceller, müşteri iade talebi açar, ödeme onaylanır, kargo takip numarası girilir. Bu olayların her biri başka bir süreci tetiklemeli. Sipariş onaylandığında satıcıya bildirim gitmeli, stok sıfıra düştüğünde ürün otomatik pasife çekilmeli, iade talebi oluştuğinde muhasebe sistemine kayıt düşülmeli. Tüm bunları her seferinde manuel yapmak veya cron job'larla periyodik kontrol yapmak hem yavaş hem de hataya açık. İşte tam bu noktada webhook ve event-driven mimari devreye giriyor.

Bu rehberde, bir pazaryeri platformunda olay tabanlı mimarinin nasıl kurgulanacağını, webhook'ların güvenli ve ölçeklenebilir şekilde nasıl kullanılacağını ve gerçek zamanlı otomasyon akışlarının nasıl tasarlanacağını adım adım inceleyeceğiz.

Event-Driven Mimari Nedir ve Neden Gereklidir?

Geleneksel yazılım mimarisinde bir işlem tamamlandığında sistem "sonraki adım ne?" sorusunu sırayla sorgular. Sipariş oluşturulur → stok düşülür → e-posta gönderilir → fatura kesilir. Bu zincirleme çağrılar (chain calls) tightly coupled bir yapı oluşturur. Bir halka hata verdiğinde tüm süreç durur. Kod değiştikçe karmaşıklık katlanır.

Event-driven mimaride ise her olay (event) bağımsız bir mesaj olarak yayınlanır. Kimin dinlediği önemli değildir. "SiparişOluşturuldu" eventi yayınlanır; bildirim servisi, stok servisi, fatura servisi ve CRM servisi bu eventi kendi mantıklarıyla işler. Hiçbiri diğerini tanımaz. Bir servis çökerse diğerleri çalışmaya devam eder.

Pazaryeri bağlamında bu yaklaşım özellikle kritik çünkü platformda birbirinden bağımsız onlarca alt sistem (satıcı paneli, müşteri uygulaması, lojistik entegrasyonu, ödeme gateway'i, raporlama motoru) aynı olaylara farklı şekillerde tepki vermeli.

Event-Driven Mimariden Elde Edilen Kazanımlar

Kazanım	Açıklama	Pazaryeri Etkisi
Gevşek Bağlaşım (Loose Coupling)	Servisler birbirini tanımaz	Satıcı bildirim sistemi değişse sipariş akışı etkilenmez
Ölçeklenebilirlik	Olay kuyrukları yatay ölçeklenir	Black Friday'de 10x trafik artışı absorbe edilir
Gerçek Zamanlılık	Olay olur olmaz tetiklenir	Müşteri sipariş onayını anında alır, 5 dk beklemez
Hata Toleransı	Bir servis çökse olay kaybolmaz	Ödeme servisi geçici down olsa sipariş kuyrukta bekler
Geliştirme Hızı	Yeni özellik = yeni event listener	CRM entegrasyonu eklemek mevcut kodu değiştirmeyi gerektirmez

Webhook Nedir, Nasıl Çalışır?

Webhook, bir olay gerçekleştiğinde sistemin belirlediğiniz URL'ye HTTP POST isteği göndermesi mekanizmasıdır. API'nin sizi bilgilendirmesi için "beni arama, ben seni ararım" demektir. Polling (sürekli sorgulama) yerine push tabanlı olduğu için hem bant genişliğinden hem de zamandan tasarruf sağlar.

Pazaryerinde webhook'lar şu senaryolarda kullanılır:

• Ödeme bildirimi: Payment gateway (iyzico, Stripe, PayTR) ödeme başarılı/başarısız olduğunda webhook ile bildirir
• Kargo takip entegrasyonu: Kargo firması paket durumu değiştiğinde (şubeye ulaştı, teslim edildi, iade) webhook tetikler
• Satıcı stok senkronizasyonu: Satıcının ERP sistemi stok değiştirdiğinde webhook ile pazaryerine iletir
• Muhasebe entegrasyonu: Fatura kesildiğinde veya ödeme alındığında muhasebe yazılımına otomatik kayıt
• CRM ve pazarlama: Yeni üye kaydı, ilk sipariş, sepet terk gibi eventler pazarlama otomasyon araçlarına iletilir

Webhook Akışının Anatomisi

Bir webhook akışı şu bileşenlerden oluşur:

1. Event kaynağı: Olayı üreten sistem (sipariş servisi, ödeme gateway'i)
2. Event payload: JSON formatında olay detayları (sipariş ID, tutar, durum, zaman damgası)
3. Endpoint URL: Webhook'un gönderileceği adres (sizin sunucunuz veya üçüncü parti servis)
4. Güvenlik katmanı: İmza doğrulama (HMAC-SHA256), IP whitelist, timestamp kontrolü
5. Retry mekanizması: Endpoint yanıt vermezse kademeli beklemeyle tekrar deneme
6. Idempotency: Aynı webhook'un birden fazla kez gelmesi durumunda tekrar işlememe garantisi

Gerçek bir örnek: iyzico ödeme sonrası platformunuza şu payload'ı gönderir:

{
  "event": "payment.completed",
  "timestamp": "2026-09-02T08:30:15Z",
  "data": {
    "paymentId": "pay_abc123",
    "orderId": "ord_xyz789",
    "amount": 1250.00,
    "currency": "TRY",
    "status": "success",
    "buyerEmail": "[email protected]"
  },
  "signature": "sha256=a1b2c3d4e5..."
}

Sizin endpoint'iniz bu payload'ı alır, imzayı doğrular, sipariş durumunu "ödendi" olarak günceller ve ilgili event listener'ları tetikler (müşteriye onay e-postası, satıcıya sipariş bildirimi, muhasebe kaydının oluşturulması).

Pazaryerinde Event Bus Tasarımı

Event-driven mimarinin kalbi event bus'tır. Tüm olayların yayınlandığı ve dinleyicilere dağıtıldığı merkezî mekanizmadır. Pazaryeri ölçeğinde event bus tasarımı şu bileşenleri içerir:

Event Tanımlama ve Schema Yönetimi

Her event tipinin standart bir şeması olmalıdır. Schema yoksa, bir servisin beklediği alan başka bir servis tarafından değiştirildiğinde sessiz hatalar oluşur. Event Schema Registry kullanarak her event tipinin zorunlu alanlarını, veri tiplerini ve validasyon kurallarını tanımlayın.

Pazaryerinde sık kullanılan event tipleri:

order.created         → Yeni sipariş oluşturuldu
order.paid            → Ödeme onaylandı
order.shipped         → Kargoya verildi
order.delivered       → Teslim edildi
order.cancelled       → Sipariş iptal edildi
order.refund.started  → İade süreci başlatıldı

seller.registered     → Yeni satıcı başvurusu
seller.approved       → Satıcı onaylandı
seller.suspended      → Satıcı askıya alındı

product.listed        → Ürün listelendi
product.out_of_stock  → Stok tükendi
product.price_changed → Fiyat güncellendi

user.registered       → Yeni kullanıcı kaydı
user.first_order      → İlk sipariş tamamlandı
review.submitted      → Yorum/puan gönderildi

Message Broker Seçimi

Event bus'ın altyapısı için seçenekler:

Teknoloji	Kullanım Senaryosu	Avantaj	Dezavantaj
RabbitMQ	Orta ölçek, karmaşık routing	Esnek exchange tipleri, dead-letter queue	Cluster yönetimi karmaşık
Apache Kafka	Yüksek hacim, event sourcing	Kalıcı log, replay yeteneği	Operational overhead yüksek
Redis Streams	Düşük gecikme, basit akış	Çok hızlı, minimal altyapı	Kalıcılık garantisi sınırlı
AWS EventBridge	Bulut-native, SaaS entegrasyonu	Yönetilen servis, rule-based routing	Vendor lock-in
NATS JetStream	Lightweight, edge computing	Minimal kaynak kullanımı	Olgun ekosistem eksikliği

Pazaryerleri için çoğu durumda RabbitMQ veya Kafka uygun başlangıç noktasıdır. İlk 10.000 sipariş/gün seviyesine kadar RabbitMQ yeterli, sonrasında event sourcing ve replay gereksinimleri doğarsa Kafka'ya geçiş değerlendirilir.

Dead Letter Queue ve Hata Yönetimi

Her webhook veya event listener hata verebilir. Önemli olan bu hataların sessizce kaybolmaması. Başarısız olan mesajlar Dead Letter Queue'ya (DLQ) yönlendirilmeli. Operasyon ekibi DLQ'daki mesajları izlemeli, gerekirse manuel yeniden işleme almalı veya hata kayıtlarını analiz etmelidir.

Bir DLQ stratejisi şu kuralları içermelidir:

• Maksimum 5 retry denemesi (kademeli bekleme: 1sn, 5sn, 30sn, 5dk, 30dk)
• 5 denemeden sonra DLQ'ya taşı
• DLQ'daki mesaj 24 saat içinde müdahale edilmezse operasyon ekibine PagerDuty/Slack bildirimi
• DLQ'daki mesaj 72 saat sonra arşivle ama silme — gerektiğinde reprocess için

Webhook Güvenliği: İmza Doğrulama ve Saldırı Önleme

Webhook'lar dış dünyadan gelen HTTP istekleridir. Güvenlik önlemleri alınmazsa sahte webhook gönderilerek sipariş durumu değiştirilebilir, ödeme onaylanabilir veya hassas veriler sızdırılabilir.

HMAC İmza Doğrulama

Her webhook göndericisi, paylaşılan bir gizli anahtar (secret) ile payload'ın HMAC-SHA256 özetini hesaplar ve X-Webhook-Signature başlığıyla gönderir. Alıcı taraf aynı hesaplamayı yaparak imzayı doğrular.

import hmac
import hashlib

def verify_webhook(payload_body: bytes, signature_header: str, secret: str) -> bool:
    expected = hmac.new(
        secret.encode('utf-8'),
        payload_body,
        hashlib.sha256
    ).hexdigest()
    received = signature_header.replace('sha256=', '')
    return hmac.compare_digest(expected, received)

Bu kontrolün yapılması zorunludur. İmzasız webhook kabul eden bir pazaryeri, herhangi bir saldırganın sahte sipariş onayları gönderebileceği anlamına gelir.

Replay Saldırısı Koruması

Saldırgan meşru bir webhook'u yakalayıp tekrar gönderebilir. Bunu önlemek için:

• Her webhook'a benzersiz bir event_id ekleyin
• İşlenen event ID'leri bir cache'de (Redis SET) tutulur (TTL: 24 saat)
• Aynı event_id tekrar gelirse idempotent olarak atlanır
• timestamp alanını kontrol edin — 5 dakikadan eski webhook'ları reddedin

IP Whitelist ve Rate Limiting

Güvenilir webhook göndericilerinin IP aralıklarını whitelist'e ekleyin. Örneğin iyzico'nun webhook IP'leri bellidir. Ayrıca webhook endpoint'inize rate limit uygulayın — dakikada 1000'den fazla istek gelmesi durumunda 429 döndürün.

Gerçek Zamanlı Otomasyon Akışları: Pratik Senaryolar

Pazaryerinde webhook ve event-driven mimariyle kurabileceğiniz otomasyon akışlarına yakından bakalım.

Senaryo 1: Sipariş → Fatura → Kargo Otomasyonu

Müşteri siparişi tamamladığında başlayan otomatik akış:

1. order.paid eventi yayınlanır
2. Fatura servisi eventi dinler → e-fatura/e-arşiv servisine istek gönderir
3. Fatura oluştuğunda invoice.created eventi yayınlanır
4. Kargo entegrasyon servisi invoice.created'i dinler → kargo firmasına gönderim isteği
5. Kargo firması takip numarasını webhook ile döner → shipment.created eventi
6. Müşteri bildirim servisi shipment.created'i dinler → SMS/e-posta ile takip bilgisi gönderir

Tüm bu süreç saniyeler içinde tamamlanır. Manuel müdahale gerekmez. Satıcı yalnızca paketi hazırlar ve kargoya verir.

Senaryo 2: Satıcı Performans İzleme ve Otomatik Uyarı

Bir satıcının sipariş karşılama süresi 48 saati aştığında:

1. order.shipped eventi gecikmeli olarak tetiklenmez → zamanlayıcı servisi her saat başı kontrol eder
2. Bekleyen sipariş sayısı 48 saati aşan satıcı tespit edilir
3. seller.sla_breached eventi yayınlanır
4. Satıcı ilişki yönetimi servisi otomatik uyarı e-postası gönderir
5. CRM servisi satıcı hesabına "risk" etiketi ekler
6. Dashboard servisi admin panelinde uyarı gösterir

Senaryo 3: Dinamik Fiyatlandırma Tetikleyici

Rakip fiyat değişikliğini yakalayan otomasyon:

1. Fiyat izleme servisi rakip verilerini periyodik olarak çeker
2. Rakip fiyatı belirli eşiğin altına düştüğünde competitor.price_dropped eventi
3. Fiyatlandırma motoru eventi dinler → kendi fiyatlandırma kurallarını çalıştırır
4. Kurala uygunsa product.price_changed eventi yayınlanır
5. Ürün servisi fiyatı günceller, frontend cache'i invalidate eder

Bu akış, pazaryerinde fiyatlandırma otomasyonu altyapısının temel taşlarından biridir.

Senaryo 4: Dolandırıcılık Tespiti ve Anında Müdahale

Şüpheli sipariş pattern'i tespit edildiğinde:

1. Sipariş oluşturulur → order.created eventi
2. Risk motoru eventi anında değerlendirir (IP, cihaz parmak izi, sipariş sıklığı, tutar anomali)
3. Risk skoru eşiği aşarsa order.flagged_fraud eventi
4. Otomatik olarak: sipariş hold'a alınır, müşteri hesabı geçici kısıtlanır, güvenlik ekibine bildirim gider
5. Güvenlik ekibi inceleme panelinden onay veya serbest bırakma kararı verir

Bu senaryo, pazaryeri bot koruması ve ödeme dolandırıcılığı önleme sistemleriyle entegre çalışır.

Webhook Yönetim Paneli Tasarımı

Pazaryeri platformunuzda satıcıların ve entegratörlerin webhook ayarlarını kendi başlarına yönetebileceği bir panel sunmak kritik. Bu panel şu özellikleri içermelidir:

Webhook endpoint kaydı: Kullanıcı URL girer, hangi event tiplerini dinlemek istediğini seçer, gizli anahtar (secret) otomatik üretilir.

Test webhook gönderimi: "Test Gönder" butonu örnek payload'ı gerçek endpoint'e POST eder. Yanıt kodu, gövde ve gecikme süresi gösterilir.

Delivery log: Gönderilen her webhook'un durumu (200 OK, 500 Error, Timeout), yanıt süresi, retry sayısı ve payload detayı görüntülenir. Son 7 gün saklanır.

Otomatik devre dışı bırakma: Üst üste 50 başarısız denemeden sonra webhook otomatik susturulur. Kullanıcıya e-posta bildirimi gider. Manuel yeniden etkinleştirme gerekir.

Bulk event seçimi: Tek tek event seçmek yerine "Tüm sipariş eventleri", "Tüm ödeme eventleri" gibi gruplama seçenekleri sunulur.

Event Sourcing ve CQRS: İleri Seviye Mimari

Büyük ölçekli pazaryerlerinde event sourcing pattern'i değerlendirilmelidir. Bu pattern'de her durum değişikliği bir event olarak kalıcı log'a (event store) yazılır. Mevcut durum, tüm event'lerin sırayla replay edilmesiyle hesaplanır.

Avantajları:

• Tam denetim izi: Her siparişin yaşam döngüsündeki her adım kayıtlı
• Zaman yolculuğu: Herhangi bir andaki durumu yeniden oluşturabilirsiniz
• Yeni projection ekleme: Mevcut event'lerden yeni raporlama görünümleri oluşturabilirsiniz — mevcut veriye dokunmadan
• Event replay: Bug bulunan bir consumer düzeltildikten sonra event'leri tekrar işleyebilir

CQRS (Command Query Responsibility Segregation) ile birlikte kullanıldığında yazma ve okuma modelleri ayrılır. Sipariş oluşturma (command) farklı bir veritabanına, ürün listesi görüntüleme (query) farklı bir okuma modeline (Elasticsearch, Redis cache) yazılır.

Bu mimari özellikle sipariş yönetimi otomasyonu ve tedarikçi feed otomasyonu gibi yüksek hacimli akışlarda ciddi performans avantajı sağlar.

Performans ve Ölçeklendirme Stratejileri

Event-driven mimari büyüdükçe karşılaşılan zorluklar ve çözümleri:

Event storm (olay fırtınası): Bir event'in birden fazla yeni event üretmesi ve bunun zincirleme büyümesi. Çözüm: Event'leri batch'leyin, rate limiter uygulayın, circuit breaker pattern kullanın.

Consumer lag: Event'lerin üretilme hızı, işlenme hızını aşarsa kuyruk şişer. Çözüm: Consumer sayısını artırın (partition başına bir consumer), consumer'ları optimize edin, geçici olarak event'leri compress ederek depolayın.

Out-of-order delivery: Dağıtık sistemlerde event'ler sırasız ulaşabilir. Çözüm: Her event'e monotonik artan sequence number ekleyin, consumer tarafında sıralama kontrolü yapın.

Exactly-once delivery: Ağ hatalarında aynı mesajın iki kez işlenmesini önlemek için idempotency key kullanın. Transactional outbox pattern ile veritabanı transaction'ı ve event üretimi atomik olarak birlikte gerçekleşir.

Monitoring ve Observability

Event-driven mimaride her şey asenkron olduğu için hata tespiti zordur. Kapsamlı bir gözlemlenebilirlik altyapısı şarttır:

• Distributed tracing: Her event'in tüm yaşam döngüsünü tek bir trace ID ile takip edin (OpenTelemetry, Jaeger)
• Event throughput metrikleri: Saniye başına üretilen/işlenen event sayısı (Prometheus + Grafana)
• Consumer lag dashboard: Kuyrukta bekleyen event sayısı ve tahmini tüketim süresi
• DLQ uyarıları: Dead letter queue'daki mesaj sayısı eşik değeri aşınca Slack/PagerDuty
• Webhook delivery SLA: Ortalama iletim gecikmesi, p99 gecikme, başarı oranı

Bu metrikler olmadan bir pazaryerinde gece 3'te "neden fatura servisi durdu?" sorusunun cevabını bulmak saatler sürer.

Başarıya Ulaşmak İçin Yol Haritası

Event-driven mimariye geçiş bir gecede yapılacak bir değişiklik değil, kademeli bir dönüşümdür:

Aşama 1 — Temel webhook altyapısı: Ödeme ve kargo webhook'larını güvenli şekilde dinleyin. HMAC doğrulama ve retry mekanizmasını kurun.

Aşama 2 — Event bus kurulumu: RabbitMQ veya benzeri bir message broker kurun. İlk 5-10 event tipini tanımlayın. Notification servisini bu mimariye taşıyın.

Aşama 3 — Servis ayrıştırma: Monolitik yapıdaki tightly coupled çağrıları event-based asenkron çağrılara dönüştürün. Her yeni özellik event-driven olarak tasarlanmalı.

Aşama 4 — Observability katmanı: Distributed tracing, metrik toplama ve DLQ monitoring'i devreye alın.

Aşama 5 — Event sourcing: Kritik domain'lerde (sipariş, ödeme) event sourcing pattern'e geçiş. Replay ve audit yetenekleri kazanın.

Her aşamada ölçülebilir hedefler koyun. Birinci aşamada webhook delivery success rate'in %99.5'in üzerinde olması, ikinci aşamada notification gecikmesinin 2 saniyenin altına inmesi gibi somut metriklerle ilerleyin.

Pazaryerinizde gerçek zamanlı otomasyon altyapısını doğru kurgulamak, operasyonel yükü azaltmanın ötesinde müşteri deneyimini doğrudan iyileştirir. Sipariş onayının anında gitmesi, stok durumunun gerçek zamanlı yansıması, iade sürecinin şeffaf şekilde takip edilmesi — bunların hepsi event-driven mimarinin ürünüdür. Rekabetin yoğun olduğu pazaryeri ekosisteminde bu tür altyapı yatırımları, uzun vadede platformunuzun en güçlü yanlarından biri haline gelir.

---

SSS

Webhook ve API polling arasında ne fark var? Polling'de siz sürekli sunucuya "yeni bir şey var mı?" diye sorarsınız. Webhook'ta ise sunucu bir olay gerçekleştiğinde sizi otomatik olarak bilgilendirir. Webhook daha verimli, daha hızlı ve daha az kaynak tüketen bir yaklaşımdır. Polling gereksiz trafik yaratır ve gecikme süresi (polling interval kadar) oluşur.

Webhook güvenlik imzası neden zorunlu? Webhook endpoint'iniz herkese açık bir URL'dir. İmza doğrulama olmadan herhangi biri sahte webhook göndererek sipariş durumu değiştirebilir, ödeme onaylatabilir veya hassas verilere erişebilir. HMAC-SHA256 imza doğrulama, webhook'un gerçekten beklediğiniz kaynaktan geldiğini garanti eder.

Event-driven mimari ne zaman tercih edilmemeli? Küçük ölçekli, basit akışlı projelerde event-driven mimarinin getirdiği karmaşıklık (message broker yönetimi, eventual consistency, debugging zorluğu) faydadan fazla olabilir. Günlük 100'den az sipariş işleyen bir platform için basit senkron çağrılar yeterli olabilir. Ölçek arttıkça event-driven'a geçiş değerlendirilmelidir.

Dead Letter Queue'daki mesajlarla ne yapılmalı? DLQ'ya düşen mesajlar önce analiz edilmeli. Hata consumer kodundan mı, endpoint hatasından mı yoksa payload bozukluğundan mı kaynaklanıyor tespit edilmelidir. Kod hatası düzeltildikten sonra mesajlar manuel veya otomatik olarak yeniden işleme alınabilir. Veri bozukluğu varsa kaynak sistemden yeniden çekilmelidir.

Event sourcing ile klasik veritabanı arasında seçim nasıl yapılmalı? Event sourcing, durum değişikliğinin tamamının log'lanmasını ve mevcut durumun event replay ile hesaplanmasını gerektirir. Full audit trail ve replay yeteneği gerekiyorsa (ödeme, sipariş gibi kritik domain'lerde) event sourcing uygundur. Basit CRUD işlemleri (kullanıcı profili, ürün açıklaması) için klasik veritabanı yeterlidir. İki yaklaşım aynı sistemde yan yana kullanılabilir.