Şirket çapında bir bildirim servisini nasıl tasarlarsınız?

Question

IT Interview Practice · Accepted Answer

Her takımın bir **bildirim tipi + alıcı** ile çağırdığı tek bir servis inşa edin ve servisin channel, template, kullanıcı tercihleri ve önceliği çözmesine izin verin. Kilit tasarım hamlesi **priority lane**'lerdir — bir OTP, 2 milyon kullanıcılık bir pazarlama patlamasının arkasında bekleyemez.

## Mimari

```text
Services ─▶ Notify API ─▶ [validate + enrich] ─▶ Kafka topics
                                                 ├─ otp/txn  (high lane)
                                                 └─ marketing (bulk lane)
                                                      │
                            ┌──── Dispatcher (per lane) ────┐
                            │ prefs check ─▶ template render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider adapters + rate limit)
```

## Bileşenler ve akış

- **Notify API** tipli bir istek alır: `{type: "otp", user, data}`. Çağıranlar asla bir channel seçmez veya metin yazmaz — servis buna sahiptir, böylece bir template değişikliği bir kez ship edilir.
- **Tip → policy**: her **tip** bir policy'ye eşlenir. *OTP* yüksek öncelikli, SMS+Push, pazarlama opt-out'unu yok sayar, 60s'de expire olur. *Transactional* (makbuz, şifre sıfırlama) yüksektir, channel tercihlerine uyar. *Marketing* düşüktür, bulk lane'dir, opt-out ve sessiz saatlere kesinlikle uyar.
- **Priority lane**'ler ayrı consumer group'lara sahip ayrı Kafka topic'leridir. High lane neredeyse boş kalır ve milisaniyeler içinde boşalır; bulk lane, OTP latency'sine dokunmadan dakikalarca birikebilir. Bu, en önemli tek karardır.
- **Preference service** her alıcı için kontrol edilir: opt-out mu yaptı? sessiz saatler mi? channel başına toggle? frequency cap? Bir tercihi ihlal eden pazarlama burada düşürülür.
- **Template engine**, versiyonlanmış bir template + değişkenlerden yerelleştirilmiş içerik render eder, böylece metin ve kod decouple edilir.
- **Channel adapter**'lar FCM/APNs, SendGrid, Twilio'yu tek bir arayüzün arkasında sarar, her biri kendi rate limiter, retry ve DLQ'sü ile (herhangi bir bulk sender ile aynı fan-out disiplini).

## Mülakat perspektifi

Mülakatı yapanlar **sorumlulukları** ayırıp ayırmadığınızı yoklar: birçok aday, doğrudan email gönderen bir monolit inşa eder, sonra pazarlama sellerinin OTP'leri geciktirdiğini keşfeder. *Priority lane*'leri, *tercih zorlamayı* ve *idempotency key*'leri (böylece yeniden denenen bir istek çift bildirim yapmaz) adlandırmak kıdemli sinyalidir. İyi, channel ekler; harika, OTP ve pazarlamanın neden asla bir kuyruk paylaşmaması gerektiğini ve bir **fallback chain**'in (Push başarısız → SMS) nasıl çalıştığını açıklar.

## Ödünleşimler ve hata

- **Tek servis vs takım başına**: merkezileştirme tutarlı tercihler, throttling ve audit sağlar, ancak kritik bir bağımlılık haline gelir — HA olmalıdır, yoksa bir login OTP kesintisi tüm şirketi bloke eder.
- **Real-time vs maliyet**: SMS pahalı ve yavaştır; Push/In-App'i tercih edin ve yalnızca yüksek değerli tipler için SMS'e geri düşün.
- **Hata**: bir sağlayıcı kesintisi sert bir hata değil, fallback chain'i tetikler. **Dedup key**'ler bir kuyruk yeniden tesliminin bir OTP'yi iki kez göndermesini önler. Tip başına teslimat SLO'larını izleyin — gecikmiş bir pazarlama email'i sorun değil, gecikmiş bir OTP bir olaydır.

Mimari

Bileşenler ve akış

Mülakat perspektifi

Ödünleşimler ve hata

İlgili sorular