Un service ou plusieurs : quand diviser
Pourquoi un monolithe n'est pas un gros mot
Un système est plus facile à déployer, déboguer et modifier entre domaines. La plupart des projets divisés tôt ont reçu tout le coût de la division — réseau, versions, surveillance distribuée, cohérence — avant d'en tirer le moindre bénéfice.
Signes que c'est le moment
Une publication bloquée parce que les équipes s'attendent ; un composant avec des besoins en ressources totalement différents ; une partie qui nécessite un niveau de disponibilité ou une réglementation distincte ; un rythme de changement très différent entre zones.
Le signe qui ne suffit pas : « parce que c'est comme ça qu'on construit aujourd'hui ».
Comment diviser correctement
Selon une frontière commerciale et non selon une couche technique. Chaque service détient ses propres données et n'appelle pas la base de données d'un autre. Communication via un contrat explicite, et des événements plutôt que des appels synchrones là où c'est possible.
Avant de diviser, vérifiez que les frontières fonctionnent à l'intérieur du monolithe lui-même : des modules bien séparés sont une répétition générale peu coûteuse.
Pour aller plus loin
La division nécessite une infrastructure : traçage distribué, surveillance par service, gestion de la configuration et un standard partagé pour les erreurs et les réessais. Si cette infrastructure n'existe pas, la division ne résoudra pas un problème de rythme mais le remplacera par un problème d'exploitation.