Retour d'expérience sur 18 mois d'évolution progressive — postgres tuning, sharding, queues, monitoring. Ce qui a marché et ce qu'on referait autrement.
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.
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.