Bir bildirim (notification) sistemi nasıl tasarlanır?

Gereksinimler

• Kanallar: uygulama içi, e-posta, SMS, mobil push.
• Kullanıcı tercihleri (hangi kanaldan, hangi tür bildirim), sessiz saatler.
• Yüksek hacim, yeniden deneme, aynı bildirimin iki kez gitmemesi.

Mimari

Servisler -> Notification API -> Kuyruk -> Kanal worker'ları -> Sağlayıcılar
 (sipariş,      (doğrulama,      (Kafka/    (email, sms,        (SES, Twilio,
  yorum...)      tercih, şablon)  SQS)       push, in-app)       FCM, APNs)

1. Olay üreten servis {userId, type, data, idempotencyKey} gönderir.
2. Notification servisi tercihleri ve sessiz saatleri kontrol eder, şablonu doldurur, kanal başına iş üretir.
3. Her kanal ayrı kuyruk ve worker'a sahiptir; SMS sağlayıcısının yavaşlaması e-postayı etkilemez.
4. Worker sağlayıcıyı çağırır; hata olursa üstel geri çekilme (exponential backoff) ile yeniden dener, kalıcı hatalar dead-letter queue'ya gider.
5. Durum (queued, sent, delivered, failed) veritabanına yazılır.

Kritik noktalar

• Idempotency: kuyruklar genelde "en az bir kez" teslim eder; idempotencyKey ile tekrarlar elenir.
• Uygulama içi bildirim: veritabanına yazılır, kullanıcı çevrim içiyse WebSocket/SSE ile anında itilir, okunmamış sayısı cache'lenir.
• Önceliklendirme: şifre sıfırlama kodu ile pazarlama e-postası aynı kuyrukta beklememeli.
• Toplama (batching): "5 kişi gönderini beğendi" gibi birleştirme spam'i azaltır.
• Sağlayıcı kotaları için kanal bazında rate limit.