Cum ai proiecta un serviciu de notificări la nivel de companie?

Question

IT Interview Practice · Accepted Answer

Construiește un singur serviciu pe care fiecare echipă îl apelează cu un **tip de notificare + destinatar**, iar serviciul rezolvă canalul, template-ul, preferințele utilizatorului și prioritatea. Decizia-cheie de design sunt **benzile de prioritate (priority lanes)** — un OTP nu poate aștepta în spatele unui blast de marketing către 2M de utilizatori.

## Arhitectură

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

## Componente și flux

- **Notify API** primește un request tipat: `{type: "otp", user, data}`. Apelanții nu aleg niciodată un canal și nu scriu conținut — serviciul deține asta, deci o schimbare de template se livrează o singură dată.
- **Tip → politică**: fiecare **tip** se mapează la o politică. *OTP* este high-priority, SMS+Push, ignoră opt-out-ul de marketing, expiră în 60s. *Tranzacțional* (chitanță, resetare parolă) este high, respectă preferințele de canal. *Marketing* este low, banda bulk, respectă strict opt-out-ul și orele de liniște.
- **Benzile de prioritate** sunt topic-uri Kafka separate cu consumer group-uri separate. Banda high rămâne aproape goală și se golește în milisecunde; banda bulk se poate aglomera minute întregi fără să atingă latența OTP-ului. Aceasta este decizia individuală cea mai importantă.
- **Serviciul de preferințe** este verificat per destinatar: opted out? ore de liniște? toggle per canal? plafon de frecvență? Marketingul care încalcă o preferință este eliminat aici.
- **Template engine-ul** randează conținut localizat dintr-un template versionat + variabile, astfel încât conținutul și codul să fie decuplate.
- **Adaptoarele de canal** înfășoară FCM/APNs, SendGrid, Twilio în spatele unei singure interfețe, fiecare cu propriul rate limiter, retry și DLQ (aceeași disciplină de fan-out ca orice bulk sender).

## Perspectiva de interviu

Intervievatorii verifică dacă separi **preocupările (concerns)**: mulți candidați construiesc un monolit care trimite email direct, apoi descoperă că inundațiile de marketing întârzie OTP-urile. A numi *benzile de prioritate*, *aplicarea preferințelor* și *cheile de idempotență* (astfel încât un request reîncercat să nu notifice de două ori) este semnalul de senior. Un răspuns bun adaugă canale; unul excelent explică de ce OTP-ul și marketingul nu trebuie să împartă niciodată o coadă și cum funcționează un **lanț de fallback** (Push eșuează → SMS).

## Compromisuri și eșecuri

- **Un serviciu vs per echipă**: centralizarea oferă preferințe, throttling și audit consistente, dar devine o dependență critică — trebuie să fie HA, altfel o cădere a OTP-ului de login blochează întreaga companie.
- **Real-time vs cost**: SMS-ul este scump și lent; preferă Push/In-App și cazi înapoi pe SMS doar pentru tipurile de mare valoare.
- **Eșec**: o cădere de furnizor declanșează lanțul de fallback, nu un eșec dur. **Cheile de dedup** împiedică o redistribuire din coadă să trimită un OTP de două ori. Urmărește SLO-urile de livrare per tip — un email de marketing întârziat e în regulă, un OTP întârziat este un incident.

Arhitectură

Componente și flux

Perspectiva de interviu

Compromisuri și eșecuri

Întrebări conexe