Si do ta projektonit një shërbim njoftimesh në nivel të gjithë kompanisë?

Question

IT Interview Practice · Accepted Answer

Ndërtoni një shërbim të vetëm që çdo ekip e thërret me një **lloj njoftimi + marrës**, dhe lëreni shërbimin të zgjidhë kanalin, template-in, preferencat e përdoruesit dhe prioritetin. Vendimi kyç i dizajnit është **priority lanes** — një OTP nuk mund të presë prapa një blast marketingu me 2M përdorues.

## Arkitektura

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

## Komponentët dhe rrjedha

- **Notify API** merr një request të tipizuar: `{type: "otp", user, data}`. Thirrësit kurrë nuk zgjedhin një kanal ose nuk shkruajnë tekstin — shërbimi e zotëron këtë, kështu që një ndryshim template-i shpërndahet një herë.
- **Type → policy**: çdo **type** hartohet në një policy. *OTP* është me prioritet të lartë, SMS+Push, injoron marketing opt-out, skadon në 60s. *Transactional* (faturë, reset fjalëkalimi) është i lartë, respekton preferencat e kanalit. *Marketing* është i ulët, bulk lane, respekton rreptësisht opt-out dhe quiet hours.
- **Priority lanes** janë Kafka topics të veçantë me consumer groups të veçantë. High lane mbetet gati bosh dhe zbrazet në milisekonda; bulk lane mund të mbushet për minuta pa prekur latency-n e OTP-së. Ky është vendimi i vetëm më i rëndësishëm.
- **Preference service** kontrollohet për çdo marrës: opt-out? quiet hours? toggle për kanal? frequency cap? Marketingu që shkel një preferencë hidhet këtu.
- **Template engine** rendon përmbajtje të lokalizuar nga një template i versionuar + variabla, kështu që teksti dhe kodi janë të decoupled.
- **Channel adapters** mbështjellin FCM/APNs, SendGrid, Twilio prapa një interfejsi të vetëm, secili me rate limiter-in, retry-n dhe DLQ-në e vet (i njëjti disiplinë fan-out si çdo dërgues bulk).

## Këndvështrimi i intervistës

Intervistuesit heton nëse i ndani **concerns**: shumë kandidatë ndërtojnë një monolit që dërgon email drejtpërdrejt, pastaj zbulojnë se përmbytjet e marketingut vonojnë OTP-të. Emërtimi i *priority lanes*, *preference enforcement*, dhe *idempotency keys* (që një request i riprovuar të mos njoftojë dy herë) është sinjali senior. Mira shton kanale; e shkëlqyer shpjegon pse OTP dhe marketing nuk duhet të ndajnë kurrë një queue dhe si funksionon një **fallback chain** (Push dështon → SMS).

## Kompromiset dhe dështimi

- **Një shërbim vs për çdo ekip**: centralizimi jep preferenca, throttling dhe audit konsistente, por bëhet një varësi kritike — duhet të jetë HA, ose një ndërprerje e OTP-së për login bllokon të gjithë kompaninë.
- **Real-time vs kosto**: SMS është i shtrenjtë dhe i ngadaltë; preferoni Push/In-App dhe kthehuni te SMS vetëm për tipa me vlerë të lartë.
- **Dështimi**: një ndërprerje provider-i shkakton fallback chain-in, jo një dështim të fortë. **Dedup keys** parandalojnë që një ridërgim queue të dërgojë një OTP dy herë. Ndiqni SLO-të e dorëzimit për çdo tip — një email marketingu i vonuar është në rregull, një OTP i vonuar është një incident.

Arkitektura

Komponentët dhe rrjedha

Këndvështrimi i intervistës

Kompromiset dhe dështimi

Pyetje të ngjashme