Hogyan terveznél egy vállalatszintű értesítési szolgáltatást?

Question

IT Interview Practice · Accepted Answer

Építs egy szolgáltatást, amelyet minden csapat egy **értesítés típussal + címzettel** hív meg, és hagyd, hogy a szolgáltatás oldja fel a csatornát, sablont, felhasználói beállításokat és prioritást. A kulcsfontosságú tervezési lépés a **prioritási sávok** — egy OTP nem várhat egy 2M-felhasználós marketing kampány mögött.

## Architektúra

```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)
```

## Komponensek és folyamat

- **Notify API** egy típusos requestet fogad: `{type: "otp", user, data}`. A hívók soha nem választanak csatornát vagy írnak szöveget — ez a szolgáltatás dolga, így egy sablonváltozás egyszer szállítódik.
- **Típus → policy**: minden **típus** egy policyre képződik le. Az *OTP* magas prioritású, SMS+Push, figyelmen kívül hagyja a marketing opt-outot, 60 mp alatt lejár. A *Tranzakciós* (nyugta, jelszó-visszaállítás) magas, tiszteletben tartja a csatorna-beállításokat. A *Marketing* alacsony, bulk sáv, szigorúan betartja az opt-outot és a csendes órákat.
- **Prioritási sávok** külön Kafka topicok külön consumer groupokkal. A magas sáv közel üres marad és milliszekundumok alatt kiürül; a bulk sáv percekig feltorlódhat anélkül, hogy az OTP latenciáját érintené. Ez a legfontosabb egyetlen döntés.
- **Preference service** címzettenként ellenőrzött: opt-outolt? csendes órák? csatornánkénti kapcsoló? gyakorisági sapka? Az a marketing, amely megsért egy beállítást, itt lesz eldobva.
- **Template engine** verziózott sablonból + változókból renderel lokalizált tartalmat, így a szöveg és a kód szét van csatolva.
- **Csatorna-adapterek** az FCM/APNs, SendGrid, Twilio szolgáltatásokat egyetlen interfész mögé csomagolják, mindegyik saját rate limiterrel, retryval és DLQ-val (ugyanaz a fan-out fegyelem, mint bármely bulk küldőnél).

## Interjú szemszög

Az interjúztatók azt vizsgálják, elkülöníted-e a **felelősségi köröket (concerns)**: sok jelölt egy monolitot épít, amely közvetlenül küld emailt, majd rájön, hogy a marketing áradatok késleltetik az OTP-ket. A *prioritási sávok*, a *beállítás-betartatás* és az *idempotencia kulcsok* (hogy egy újrapróbált request ne értesítsen duplán) megnevezése a senior jel. A jó csatornákat ad hozzá; a kiváló megmagyarázza, miért nem oszthat soha közös queue-t az OTP és a marketing, és hogyan működik egy **fallback lánc** (Push meghiúsul → SMS).

## Kompromisszumok és hibák

- **Egy szolgáltatás vs csapatonkénti**: a központosítás konzisztens beállításokat, throttlingot és auditot ad, de kritikus függőséggé válik — HA-nak kell lennie, különben egy bejelentkezési OTP kiesés az egész vállalatot blokkolja.
- **Valós idő vs költség**: az SMS drága és lassú; preferáld a Push/In-App-et, és csak a nagy értékű típusoknál ess vissza SMS-re.
- **Hiba**: egy szolgáltatói kiesés a fallback láncot indítja, nem egy kemény hibát. A **dedup kulcsok** megakadályozzák, hogy egy queue újraküldés kétszer küldjön OTP-t. Kövesd a típusonkénti kézbesítési SLO-kat — egy késleltetett marketing email rendben van, egy késleltetett OTP incidens.

Architektúra

Komponensek és folyamat

Interjú szemszög

Kompromisszumok és hibák

Kapcsolódó kérdések