---
title: "Günde 10 Milyon Olay İçin Webhook Dağıtım Sistemi Tasarımı"
url: https://blog.edumints.com/gunde-10-milyon-olay-icin-webhook-dagitim-sistemi-tasarimi-6cdb0d6q
category: "Yazılım"
date: 2026-09-06T15:08:25.807Z
publisher: Edumints Blog
lang: tr-TR
source_name: "dev.to"
source_url: https://dev.to/lovestaco/designing-a-webhook-delivery-system-for-10-million-events-a-day-2p5d
---

# Günde 10 Milyon Olay İçin Webhook Dağıtım Sistemi Tasarımı

Bir planlama toplantısında ya da Jira'daki üç kelimelik bir göreve bakarken ekibinizden biri mutlaka şunu söyleyecektir: *"Webhook mu? Altı üstü bir POST isteği, yarım günlük iş."* Teknik olarak haksız sayılmazlar; webhook özünde sisteminizdeki bir olayı müşteriye HTTP isteğiyle bildirmekten ibarettir. Ancak sistemi doğrudan bu şekilde canlıya alırsanız, altı hafta sonra müşterinin sunucusu kapalıyken kaçan 4.000 ödeme bildirimini açıklamak zorunda kalırsınız.

Günde 10 milyon olay —saniyede ortalama 115, zirve anlarda ise çok daha fazlası— işleyen dayanıklı bir mimari kurmak için naif yaklaşımdan başlayıp üretim şartlarında adım adım ilerleyelim.

## Versiyon 1: Sadece POST İsteği Göndermek (Naive Yaklaşım)

En bariz yöntem, olay gerçekleştiğinde istek işleyicisi (request handler) içinden doğrudan müşterinin URL'ine istek atıp `200 OK` yanıtı beklemektir.

- **Çalışma Şekli**: Ödeme veritabanına kaydedilir ve hemen ardından istemciye senkron bir POST isteği atılır. Test ortamında kusursuz çalışan bu kurgu, üretim ortamında hızla dağılır.
- **Neden Çöker?**: Müşterinizin uç noktası, aynı zamanda cron işleri de koşturan küçük bir sunucuda barınıyor olabilir. Saat 15:00'te başlayan bir cron nedeniyle müşteri sunucusunun yanıt süresi sekiz saniyeye çıktığında, sizin istek işleyiciniz harici bir altyapıyı bekleyerek thread'leri kilitler. Bağlantı havuzunuz (connection pool) hızla tükenir, gecikmeler fırlar ve sistemdeki ilgisiz diğer kullanıcılar dahi zaman aşımı (timeout) hataları almaya başlar.
- **Pratik Çıkarım**: İstek zaman aşımına uğradığında süreç devam eder ve olay kaybolur; çünkü veri sadece sonlanan fonksiyonun geçici belleğindedir. Buradaki asıl mimari hata yavaşlık değil, kendi sistem erişilebilirliğinizi (availability) kritik işlem yolunda (hot path) doğrudan müşterinin erişilebilirliğine bağlamış olmanızdır.

## Versiyon 2: Önce Bir Yere Kaydetmek (Transactional Outbox Deseni)

Dağıtık sistemlerin ve yazılım geliştirmenin bir numaralı kuralı: Bir işi yapmaya çalışmadan önce mutlaka kalıcı olarak kaydedin.

- **Çalışma Şekli**: İstek işleyicisi doğrudan HTTP isteği atmayı bırakır. Olayı, ödeme kaydıyla aynı veritabanı işlemi (transaction) içinde bir outbox tablosuna yazar (`BEGIN ... COMMIT`). Böylece istek işleyicisi derhal başarılı yanıt döner.
- **Neden Başarılıdır?**: Ödemeyi veritabanına yazıp ardından harici bir kuyruğa mesaj göndermeye kalkarsanız, iki sistem arasında bir çökme boşluğu (gap) doğar. Transactional Outbox deseni sayesinde ödeme ile webhook kaydı atomik olarak birbirine bağlanır; ya ikisi birden gerçekleşir ya da hiçbiri.
- **Pratik Çıkarım**: Ayrı bir arka plan çalışanı (worker) bekleyen satırları düzenli olarak sorgular ve gönderimleri asenkron yürütür. Böylece ana sistemin performansı korunur, veriler dayanıklı (durable) kılınır ve teslimat başarısız olsa dahi güvenli bir yeniden deneme (retry) zemini elde edilir.

[Orijinal kaynağa buradan ulaşabilirsiniz.](https://dev.to/lovestaco/designing-a-webhook-delivery-system-for-10-million-events-a-day-2p5d)

---

**Kaynak:** [dev.to](https://dev.to/lovestaco/designing-a-webhook-delivery-system-for-10-million-events-a-day-2p5d)
**Yayıncı:** [Edumints Blog](https://blog.edumints.com) · Alıntılarken bu URL'ye bağlantı verin: https://blog.edumints.com/gunde-10-milyon-olay-icin-webhook-dagitim-sistemi-tasarimi-6cdb0d6q