Étude : plateforme de notifications

Prérequis : chapitres 4, 5 et 7 (tout le cursus, c'est la synthèse).

Pourquoi

La théorie sans synthèse ne tient pas. On conçoit ici un vrai système — notifications multi-canaux (mail, SMS, push) — en appliquant chaque chapitre, avec les trade-offs explicites.

Concepts mobilisés

• Besoin : 1 M notifs/jour, 3 canaux, priorités (OTP en secondes, newsletter en heures), traçabilité (qui a reçu quoi, statut).
• Découpage : API d'envoi (validation + file) → workers par canal (retry/rate-limit spécifiques) → suivi statuts (webhooks prestataires). Chaque morceau = cohésion forte, couplage faible (ch. 1).
• Modèle : agrégat Notification (destinataire, contenu, statut) + événements (notification.queued/sent/failed) + projections (dashboard « mes envois ») — ch. 3 et 4.
• Résilience : prestataire SMS down → breaker + file d'attente + bascule secondaire ; retry backoff+jitter ; idempotence par messageId (ch. 5 et 7).

Exemple : les décisions (ADR !)

ADR-01 : Postgres + file (pas Kafka) — 1 M/jour tient sans streaming distribué (YAGNI).
ADR-02 : topics par canal — workers indépendants, scaling séparé.
ADR-03 : OTP synchrone (< 2 s, timeout court), newsletter async pure.

Cas réel (inspiré)

Plateforme qui envoyait tout en direct : le SMTP lent bloquait l'API, un prestataire down = tout down. Après refonte (file + workers + breakers) : p95 divisé par 10, prestataire down = invisible. Même code métier, autre architecture.

Pièges (de l'exercice)

• Kafka « parce que c'est ce qu'on fait » pour 1 M/jour : YAGNI — Postgres + file suffit, Kafka attendra 100×.
• Synchrone partout « pour simplifier le debug » : l'OTP oui, la newsletter non — chaque besoin son mode.
• Oublier le suivi : sans statuts, le support est aveugle (« mon SMS est parti ? » → inconnu).

À retenir

Besoin → découpage → modèle → résilience, chaque choix en ADR, YAGNI jusqu'à preuve du volume.