Kif tiddisinja notification service għall-kumpanija kollha?

Question

IT Interview Practice · Accepted Answer

Ibni servizz wieħed li kull team isejjaħ b'**tip ta' notifika + reċipjent**, u ħalli s-servizz jirriżolvi l-channel, template, preferenzi tal-utent, u prijorità. Il-mossa ewlenija fid-disinn hija l-**priority lanes** — OTP ma jistax jistenna wara marketing blast ta' 2M utent.

## Arkitettura

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

## Komponenti u fluss

- **Notify API** tieħu talba tipata: `{type: "otp", user, data}`. Min isejjaħ qatt ma jagħżel channel jew jikteb il-kopja — is-servizz iżomm dan, allura bidla f'template tiġi rilaxxata darba.
- **Type → policy**: kull **type** jimmappja għal policy. *OTP* huwa high-priority, SMS+Push, jinjora l-marketing opt-out, jiskadi f'60s. *Transactional* (irċevuta, password reset) huwa high, jirrispetta l-channel prefs. *Marketing* huwa low, bulk lane, josserva strettament l-opt-out u l-quiet hours.
- **Priority lanes** huma Kafka topics separati b'consumer groups separati. Il-high lane tibqa' kważi vojta u tbattal f'millisekondi; il-bulk lane tista' timtela għal minuti mingħajr ma tmiss il-latenza tal-OTP. Din hija l-aktar deċiżjoni importanti waħedha.
- **Preference service** jiġi ċċekkjat għal kull reċipjent: opted out? quiet hours? toggle għal kull channel? frequency cap? Marketing li jikser preferenza jiġi mwaqqa' hawn.
- **Template engine** tirrenderja kontenut lokalizzat minn template versjonat + varjabbli, biex il-kopja u l-kodiċi jkunu decoupled.
- **Channel adapters** jgħattu FCM/APNs, SendGrid, Twilio wara interface wieħed, kull wieħed bir-rate limiter, retry, u DLQ tiegħu (l-istess dixxiplina ta' fan-out bħal kull bulk sender).

## Perspettiva tal-intervista

L-intervistaturi jgħarblu jekk tissepara l-**concerns**: ħafna kandidati jibnu monolith li jibgħat email direttament, imbagħad jiskopru li għargħar ta' marketing jittardja l-OTPs. Li ssemmi *priority lanes*, *preference enforcement*, u *idempotency keys* (biex talba mibgħuta mill-ġdid ma tinnotifikax darbtejn) huwa s-sinjal senior. Tajjeb iżid channels; eċċellenti jispjega għaliex OTP u marketing qatt m'għandhom jaqsmu queue u kif taħdem **fallback chain** (Push jfalli → SMS).

## Trade-offs u fallimenti

- **Servizz wieħed vs għal kull team**: iċ-ċentralizzar jagħti prefs, throttling, u audit konsistenti, imma jsir dipendenza kritika — irid ikun HA, inkella outage ta' login OTP jimblokka l-kumpanija kollha.
- **Real-time vs kost**: SMS huwa għali u bil-mod; ippreferi Push/In-App u aqbeż għal SMS biss għal tipi ta' valur għoli.
- **Fallimenti**: outage ta' provider jiskatta l-fallback chain, mhux falliment iebes. **Dedup keys** jipprevjenu li redelivery ta' queue jibgħat OTP darbtejn. Żomm delivery SLOs għal kull tip — email tal-marketing ittardjata hija tajba, OTP ittardjat huwa inċident.

Arkitettura

Komponenti u fluss

Perspettiva tal-intervista

Trade-offs u fallimenti

Mistoqsijiet relatati