Design sprint adapté, artefacts livrés, cas concret.
Ce n’est pas un tutoriel — c’est un retour d’expérience. Chaque décision est datée, chaque bénéfice mesuré, chaque regret assumé.
1. La lecture avant l’écriture
Notre première optimisation n’a pas été de scaler l’écriture, mais la lecture. 80% du trafic était en read — dashboards, historiques, vérifications de solde. On a introduit une réplique read-only + Redis pour cacher les vues les plus consultées.
// résultat semaine +2
latence p50 210ms → 45ms
load db primaire 78% → 34%
cache hit ratio 89%
« Le bon réflexe c’est de tout scaler tout de suite. Le meilleur, c’est d’observer d’abord — puis d’agir là où ça compte. »
2. Découpage progressif du monolithe
On n’est pas passé aux microservices d’un coup. On a extrait 3 services critiques dans cet ordre — chacun avec sa DB, ses métriques, son SLO :
- Service transactions — le cœur, sorti en premier (juin 2024)
- Service KYC — flow long, découpé pour absorber les pics (sept. 2024)
- Service notifications — worker asynchrone, SMS + push (janv. 2025)
Le reste (settings, admin, reporting) est resté dans le monolithe. Il tourne toujours en prod aujourd’hui.