Comment une startup en pleine croissance a failli couler six mois après avoir adopté une MSA

J’ai récemment lu un article devenu viral sur un blog tech étranger, "Microservices Killed Our Startup. Monoliths Would’ve Saved Us", et son contenu était à la fois si douloureusement juste et si parlant que j’en partage ici un résumé.

Cela ressemble à une excellente « fiche d’erreurs à ne pas reproduire » sur les dangers d’adopter les dernières technologies de manière dogmatique.

---

1. Le point de départ : « Faisons comme Netflix, nous aussi »

• Contexte : levée seed de 2,5 M$, croissance mensuelle du chiffre d’affaires de 40 %, 50 000 utilisateurs. Une startup qui tournait très bien avec un monolithe Rails.
• Début du problème : un lead architect arrive et propose une transition vers une MSA au nom de la « scalabilité ».
• Logique : « Notre architecture actuelle est trop couplée. Regardez Netflix ou Uber. Si on veut devenir comme eux, il faut passer aux microservices. »
• Réalité : une équipe de 4 développeurs et 1 ingénieur DevOps décide d’adopter une architecture façon Netflix.

2. Six mois d’enfer (chronologie de l’adoption de la MSA)

[Mois 1 : lune de miel]

• La séparation du service de notifications est un succès. « Vous voyez ? Ça marche très bien ! » se félicite l’équipe.
• Mais les premiers signes avant-coureurs apparaissent : temps de déploiement plus longs, multiplication des dépôts, etc.

[Mois 2 à 3 : les premières fissures]

• Le service de facturation (Billing) est séparé. Or il est lié aux services utilisateurs, stock et commandes.
• Résultat : à cause de la latence réseau, le temps de réponse passe de 200 ms à 800 ms. Quand un service tombe, il entraîne des pannes en cascade sur l’ensemble du système.

[Mois 4 à 5 : le cauchemar des transactions distribuées]

• Là où une simple transaction DB suffisait dans le monolithe, l’environnement distribué impose même l’adoption du pattern Saga.
• Le stock diminue mais le paiement échoue, les rollbacks s’emmêlent... et l’incohérence des données déclenche une avalanche de tickets support.
• Ajouter une simple colonne oblige à toucher 6 services : ce qui prenait 2 heures demande désormais 3 jours.

[Mois 6 : l’effondrement de l’équipe]

• Les développeurs consacrent tout leur temps à gérer l’infrastructure au lieu de développer des fonctionnalités.
• Coût d’infrastructure : 3 000 $ → 12 000 $ (multiplié par 4).
• Départ d’un développeur clé (« Je suis venu pour construire un produit, pas pour passer mes journées à bricoler Kubernetes. »)

3. La décision : « Nous ne sommes pas Netflix »

L’architecte continue pourtant d’insister : « adoptons un Service Mesh et ajoutons plus d’outils de monitoring ». Mais l’auteur finit par exploser.

> « Nous ne sommes pas Netflix ! Netflix a 500 ingénieurs, nous sommes 4 ! »

Finalement, l’architecte quitte l’entreprise et l’équipe décide de revenir au monolithe (rollback).

4. Retour au monolithe, puis renaissance

• Pendant 8 semaines, l’équipe réintègre le code dans un monolithe.
• Résultats :
• reprise de la vitesse de livraison des fonctionnalités (de 4 à 20 par mois)
• temps de réponse stabilisé à 220 ms
• baisse des coûts d’infrastructure
• et surtout, hausse du bonheur des développeurs

5. Leçons essentielles (la conclusion de l’article)

1. La MSA n’est pas un outil pour résoudre un “problème technique”, mais un “problème organisationnel”.

• On l’utilise quand il y a plus de 50 développeurs qui se marchent dessus, ou quand les cycles de déploiement divergent trop fortement.

2. Netflix/Google ne sont pas vos modèles.

• Eux aussi ont commencé avec un monolithe. Ils ont changé d’architecture à cause de leur échelle, pas dès le départ.

3. La complexité est une taxe.

• À mesure que les services se multiplient, le coût de gestion augmente de façon composée.

4. Les appels réseau ne sont pas gratuits.

• Un appel de fonction en mémoire (nanosecondes) et un appel réseau (millisecondes), ce n’est pas du tout le même ordre de grandeur.

---

Résumé en une phrase :
« Le monolithe n’est pas l’ennemi. Le vrai ennemi, c’est une mauvaise architecture. Pour une équipe de 4 personnes, par pitié, utilisez simplement un monolithe. »