Simulateur de Décisions

Au bout de 4 mois, l’équipe a réalisé 30 % du travail. Le monolithe continue de recevoir de nouvelles fonctionnalités parce que le métier ne peut pas attendre. Vous avez désormais deux systèmes à maintenir et l’équipe est divisée. Le CTO commence à demander quand ce sera prêt.

Leçon : Les réécritures complètes se terminent presque jamais à temps. Le métier ne s’arrête pas pendant que vous réécrivez.

Au bout de 3 mois, vous avez extrait le service de notifications. Les déploiements du monolithe sont un peu plus rapides. L’équipe a appris la communication entre services, le service discovery et le monitoring distribué. Vous pouvez maintenant planifier la prochaine extraction avec plus de confiance.

Leçon : Le pattern Strangler Fig permet de migrer progressivement avec un risque maîtrisé. Chaque extraction apporte des enseignements pour la suivante.

Au bout de 2 mois, le monolithe est organisé en modules avec des interfaces claires. Les conflits de merge ont diminué de 60 %. Les déploiements prennent toujours 45 minutes, mais vous pouvez désormais faire des déploiements partiels par module. L’équipe dispose d’une base solide pour extraire des services à l’avenir si nécessaire.

Leçon : Parfois, la meilleure architecture distribuée est celle dont vous n’avez pas besoin. Un monolithe bien organisé peut passer à l’échelle plus que vous ne le croyez.

PostgreSQL gère bien les 500K lignes et les requêtes complexes. Au bout de 6 mois, les lectures commencent à saturer la base de données. Vous ajoutez une read replica et le problème est résolu. L’historique des changements, vous l’implémentez avec une table d’audit et des triggers.

Leçon : PostgreSQL est un choix solide pour la plupart des cas. Ne sous-estimez pas jusqu’où peut aller une base de données relationnelle bien configurée.

MongoDB fonctionne bien au début. Au bout de 3 mois, vous découvrez que les requêtes d’agrégation avec plusieurs filtres sont plus lentes que prévu. Le schéma flexible a provoqué des incohérences dans les données parce que différentes parties de l’équipe enregistraient les documents avec des structures légèrement différentes.

Leçon : La flexibilité du schéma est une arme à double tranchant. Sans discipline, elle génère de la dette technique. MongoDB excelle lorsque le modèle de données est réellement hiérarchique.

La combinaison fonctionne très bien pour les lectures. Mais au bout de 2 mois, vous découvrez des bugs d’invalidation de cache : certains utilisateurs voient des données stale après des mises à jour. Vous implémentez un système d’invalidation basé sur les événements et le problème est résolu, mais la complexité opérationnelle a augmenté significativement.

Leçon : Ajouter un cache résout des problèmes de performance mais introduit des problèmes de cohérence. N’ajoutez un cache que lorsque vous en avez réellement besoin, pas « au cas où ».

Ça fonctionne, mais la réconciliation entre deux fournisseurs est complexe. Certains paiements sont traités par Stripe et d’autres par PayPal, ce qui complique les rapports financiers. De plus, PayPal a son propre taux de pannes — il n’est pas immunisé. Au bout de 3 mois, vous disposez d’un système plus résilient mais nettement plus complexe à exploiter.

Leçon : Plusieurs fournisseurs augmentent la disponibilité mais multiplient la complexité. Évaluez si le coût opérationnel justifie l’amélioration de la disponibilité.

Les reprises automatiques résolvent 90 % des pannes transitoires. Mais vous découvrez un problème : certains paiements sont traités deux fois parce que la reprise arrive alors que Stripe avait déjà traité le premier (mais avait répondu par un timeout). Vous implémentez l’idempotence avec des clés uniques et le problème est résolu.

Leçon : Les reprises sans idempotence sont dangereuses. Implémentez toujours l’idempotence avant de mettre en place des reprises automatiques.

Le circuit breaker détecte les pannes en quelques secondes et cesse d’envoyer des requêtes à Stripe. Les utilisateurs voient un message clair : « Le système de paiement est temporairement indisponible. Votre panier est enregistré — vous pouvez finaliser votre achat plus tard. » L’expérience n’est pas parfaite, mais elle est honnête et ne génère pas de frustration.

Leçon : Parfois, la meilleure réponse à une panne est d’être transparent avec l’utilisateur. Tous les problèmes ne nécessitent pas des solutions techniques complexes.