Comment concevriez-vous un service de notifications à l'échelle de l'entreprise ?

Question

IT Interview Practice · Accepted Answer

Construisez un seul service que chaque équipe appelle avec un **type de notification + destinataire**, et laissez le service résoudre le canal, le template, les préférences utilisateur et la priorité. Le choix de conception clé est celui des **files prioritaires** — un OTP ne peut pas attendre derrière un envoi marketing de 2M d'utilisateurs.

## Architecture

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

## Composants et flux

- **Notify API** prend une requête typée : `{type: "otp", user, data}`. Les appelants ne choisissent jamais un canal ni ne rédigent le texte — le service en est propriétaire, donc un changement de template se déploie une seule fois.
- **Type → policy** : chaque **type** est mappé à une policy. *OTP* est haute priorité, SMS+Push, ignore l'opt-out marketing, expire en 60s. *Transactionnel* (reçu, réinitialisation de mot de passe) est haute priorité, respecte les préférences de canal. *Marketing* est basse priorité, file bulk, honore strictement l'opt-out et les heures calmes (quiet hours).
- **Files prioritaires** sont des topics Kafka séparés avec des consumer groups séparés. La file haute reste quasi vide et se vide en millisecondes ; la file bulk peut s'accumuler pendant des minutes sans toucher à la latence des OTP. C'est la décision la plus importante à elle seule.
- **Service de préférences** est vérifié par destinataire : opté-out ? heures calmes ? toggle par canal ? plafond de fréquence ? Le marketing qui viole une préférence est abandonné ici.
- **Moteur de templates** rend un contenu localisé à partir d'un template versionné + variables, pour découpler le texte et le code.
- **Adaptateurs de canaux** enveloppent FCM/APNs, SendGrid, Twilio derrière une seule interface, chacun avec son propre rate limiter, réessai et DLQ (même discipline de fan-out que tout envoyeur de masse).

## Perspective d'entretien

Les examinateurs cherchent à savoir si vous séparez les **préoccupations** : beaucoup de candidats construisent un monolithe qui envoie l'email directement, puis découvrent que les flots marketing retardent les OTP. Nommer les *files prioritaires*, l'*application des préférences*, et les *clés d'idempotence* (pour qu'une requête réessayée ne double-notifie pas) est le signal senior. Bien ajoute des canaux ; excellent explique pourquoi OTP et marketing ne doivent jamais partager une queue et comment fonctionne une **chaîne de fallback** (Push échoue → SMS).

## Compromis et pannes

- **Un seul service vs par équipe** : centraliser donne des préférences, du throttling et de l'audit cohérents, mais devient une dépendance critique — il doit être HA, sinon une panne d'OTP de connexion bloque toute l'entreprise.
- **Temps réel vs coût** : le SMS est coûteux et lent ; préférez Push/In-App et repliez-vous sur le SMS seulement pour les types à forte valeur.
- **Panne** : une panne de provider déclenche la chaîne de fallback, pas un échec dur. Les **clés de dedup** empêchent une redélivraison de queue d'envoyer un OTP deux fois. Suivez des SLO de livraison par type — un email marketing retardé est acceptable, un OTP retardé est un incident.

Architecture

Composants et flux

Perspective d'entretien

Compromis et pannes

Questions connexes