Kaip suprojektuotumėte visos įmonės mastu veikiantį pranešimų servisą?

Question

IT Interview Practice · Accepted Answer

Sukurkite vieną servisą, kurį kiekviena komanda iškviečia su **pranešimo tipu + gavėju**, ir leiskite servisui nustatyti kanalą, šabloną, naudotojo nustatymus ir prioritetą. Pagrindinis projektavimo sprendimas yra **prioritetinės juostos (priority lanes)** — OTP negali laukti už 2 mln. naudotojų marketingo šuolio.

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

## Komponentai ir eiga

- **Notify API** priima tipizuotą užklausą: `{type: "otp", user, data}`. Iškviečiantieji niekada nesirenka kanalo ir nerašo teksto — servisas tuo rūpinasi, tad šablono keitimas išleidžiamas vieną kartą.
- **Tipas → politika**: kiekvienas **tipas** susietas su politika. *OTP* yra aukšto prioriteto, SMS+Push, ignoruoja marketingo atsisakymą, galioja 60s. *Transactional* (kvitas, slaptažodžio atstatymas) yra aukšto prioriteto, gerbia kanalų nustatymus. *Marketing* yra žemo prioriteto, bulk juosta, griežtai laikosi atsisakymo (opt-out) ir tylos valandų.
- **Prioritetinės juostos** yra atskiri Kafka topics su atskiromis consumer groups. Aukšta juosta lieka beveik tuščia ir ištuštėja per milisekundes; bulk juosta gali kauptis minutėmis nepaliesdama OTP latency. Tai pats svarbiausias sprendimas.
- **Nustatymų servisas (preference service)** tikrinamas kiekvienam gavėjui: atsisakė? tylos valandos? kanalo perjungiklis? dažnio riba? Marketingas, pažeidžiantis nustatymą, atmetamas čia.
- **Šablonų variklis** atvaizduoja lokalizuotą turinį iš versijuoto šablono + kintamųjų, tad tekstas ir kodas atsiejami.
- **Kanalų adapteriai** apgaubia FCM/APNs, SendGrid, Twilio už vienos sąsajos, kiekvienas su savo rate limiter, retry ir DLQ (ta pati fan-out disciplina kaip bet kuriam bulk siuntėjui).

## Interviu perspektyva

Interviuotojai tikrina, ar atskiriate **atsakomybes**: daug kandidatų sukuria monolitą, kuris siunčia el. laiškus tiesiogiai, o paskui pastebi, kad marketingo potvyniai vėlina OTP. Įvardyti *prioritetines juostas*, *nustatymų vykdymą* ir *idempotentiškumo raktus* (kad pakartota užklausa nepraneštų dukart) yra senior signalas. Geras atsakymas prideda kanalus; puikus paaiškina, kodėl OTP ir marketingas niekada neturi dalytis eilės ir kaip veikia **atsarginė grandinė (fallback chain)** (Push nepavyksta → SMS).

## Kompromisai ir gedimai

- **Vienas servisas vs kiekvienai komandai**: centralizavimas suteikia nuoseklius nustatymus, ribojimą ir auditą, bet tampa kritine priklausomybe — jis privalo būti HA, kitaip prisijungimo OTP gedimas blokuoja visą įmonę.
- **Realaus laiko vs kaina**: SMS brangus ir lėtas; teikite pirmenybę Push/In-App ir atsargai naudokite SMS tik aukštos vertės tipams.
- **Gedimas**: tiekėjo gedimas paleidžia atsarginę grandinę, o ne kietą klaidą. **Dedup raktai** neleidžia eilės pakartotiniam pristatymui išsiųsti OTP dukart. Sekite kiekvieno tipo pristatymo SLO — pavėluotas marketingo el. laiškas normalu, pavėluotas OTP yra incidentas.

Architektūra

Komponentai ir eiga

Interviu perspektyva

Kompromisai ir gedimai

Susiję klausimai