Architecture microservices : découper sans se disperser

L'architecture microservices consiste à découper une application en services autonomes, déployables indépendamment. Séduisante sur le papier, elle n'a de valeur que si le découpage est réfléchi. Mal appliquée, elle cumule les inconvénients du monolithe et du distribué.

Découper par domaine métier

Le bon critère de découpage n'est pas technique mais métier. Un service possède un périmètre clair (les commandes, la facturation, le catalogue) et sa propre base de données. On évite de partager les tables entre services : chacun est maître de ses données.

La communication, nerf de la guerre

• Synchrone (HTTP/gRPC) : simple, mais crée un couplage temporel.
• Asynchrone (files de messages) : résilient, découplé, mais plus complexe à tracer.

Un bus de messages comme RabbitMQ ou Kafka permet aux services de réagir à des événements sans se connaître directement.

Le piège du monolithe distribué

Si modifier une fonctionnalité oblige à déployer cinq services en même temps, ce ne sont pas des microservices : c'est un monolithe distribué — le pire des deux mondes.

Commencer simple

La plupart des projets gagnent à démarrer en monolithe bien structuré, puis à extraire des services quand un besoin réel l'exige : montée en charge ciblée, équipe dédiée, cycle de déploiement distinct. Les microservices sont une réponse à un problème d'échelle, pas un point de départ par défaut.