Étude : boutique qui scale

Prérequis : chapitres 3, 4, 6 et 7.

Pourquoi

Deuxième synthèse, autre profil : parcours synchrone critique (panier → paiement) + catalogue à fort trafic. Les mêmes principes, des décisions différentes — c'est ça, l'architecture : du contexte, pas des recettes.

Concepts mobilisés

• Chemin critique : panier → paiement → confirmation doit être rapide ET fiable : timeouts courts, saga (paiement → stock → expédition + compensations), idempotence partout.
• Catalogue : lecture massive, écriture rare → CQRS naturel (projections plates + cache, invalidation par événements), CDN devant les images.
• Pic de charge : files pour lisser (commandes), feature flags pour dégrader (recommandations coupées en premier), pré-warm du cache avant l'ouverture des ventes.

Exemple : le Black Friday en 5 décisions

1. Catalogue en projection + cache (TTL court) + CDN images
2. Commandes en file (pas de 500 sous pic, de l'attente annoncée)
3. Paiement : timeout 3 s + idempotence + saga compensée
4. Recommandations : breaker + fallback (masquées si down)
5. Observabilité : dashboard temps réel (commandes/min, p95, erreurs, file)

Cas réel (inspiré)

Vente flash sans file : 10× le trafic normal, base saturée en 4 minutes, 40 minutes de down + survente (stock négatif !). Année suivante : file + quotas + projections — pic absorbé, zéro survente, équipe qui dort.

Pièges

• Optimiser le panier avant le catalogue : 95 % du trafic est en lecture — le catalogue d'abord.
• Stock en cache sans garde : survente. Le stock se vérifie à la source au paiement (cf. 6.2).
• Feature flags sans plan de retrait : 30 flags morts en 2 ans = code spaghetti. Date d'expiration par flag.

À retenir

Critique = saga + idempotence, lecture = projections + cache + CDN, pics = files + dégradation planifiée.