Come progetteresti un servizio di notifiche a livello aziendale?

Question

IT Interview Practice · Accepted Answer

Costruisci un unico servizio che ogni team chiama con un **tipo di notifica + destinatario**, e lascia che il servizio risolva canale, template, preferenze utente e priorità. La mossa progettuale chiave sono le **corsie di priorità**: un OTP non può aspettare dietro un invio marketing da 2M di utenti.

## Architettura

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

## Componenti e flusso

- **Notify API** accetta una richiesta tipizzata: `{type: "otp", user, data}`. I chiamanti non scelgono mai un canale né scrivono il testo: se ne occupa il servizio, così una modifica al template viene rilasciata una sola volta.
- **Tipo → policy**: ogni **tipo** mappa a una policy. *OTP* è ad alta priorità, SMS+Push, ignora l'opt-out marketing, scade in 60s. *Transazionale* (ricevuta, reset password) è alta, rispetta le preferenze di canale. *Marketing* è bassa, corsia bulk, rispetta rigorosamente opt-out e quiet hours.
- **Corsie di priorità** sono topic Kafka separati con consumer group separati. La corsia alta resta quasi vuota e si svuota in millisecondi; la corsia bulk può accumularsi per minuti senza toccare la latenza degli OTP. Questa è la decisione singola più importante.
- **Preference service** viene consultato per ogni destinatario: ha fatto opt-out? quiet hours? toggle per canale? frequency cap? Il marketing che viola una preferenza viene scartato qui.
- **Template engine** renderizza contenuto localizzato da un template versionato + variabili, così testo e codice sono disaccoppiati.
- **Channel adapter** incapsulano FCM/APNs, SendGrid, Twilio dietro un'unica interfaccia, ognuno con il proprio rate limiter, retry e DLQ (la stessa disciplina di fan-out di qualsiasi bulk sender).

## Prospettiva del colloquio

Gli intervistatori verificano se separi le **responsabilità**: molti candidati costruiscono un monolite che invia email direttamente, poi scoprono che i flussi marketing ritardano gli OTP. Nominare *corsie di priorità*, *enforcement delle preferenze* e *idempotency key* (così che una richiesta ritentata non notifichi due volte) è il segnale senior. Il "buono" aggiunge canali; l'"eccellente" spiega perché OTP e marketing non devono mai condividere una coda e come funziona una **catena di fallback** (Push fallisce → SMS).

## Compromessi e modalità di guasto

- **Un unico servizio vs per-team**: centralizzare dà preferenze, throttling e audit coerenti, ma diventa una dipendenza critica: deve essere in HA, altrimenti un'interruzione dell'OTP di login blocca l'intera azienda.
- **Real-time vs costo**: gli SMS sono costosi e lenti; preferisci Push/In-App e ripiega su SMS solo per i tipi ad alto valore.
- **Guasto**: un'interruzione del provider innesca la catena di fallback, non un errore netto. Le **dedup key** impediscono che una riconsegna dalla coda invii un OTP due volte. Traccia SLO di consegna per tipo: un'email marketing ritardata va bene, un OTP ritardato è un incidente.

Architettura

Componenti e flusso

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate