Choisir entre REST, gRPC, Kafka ou RabbitMQ n'est pas une question de mode. C'est un choix architectural aux conséquences durables sur la résilience, le couplage et la scalabilité.
Quand deux microservices ont besoin d'échanger des données, la première intuition est souvent un appel REST. C'est simple, connu, outillé. Mais la communication synchrone crée un couplage temporel : si le service appelé est lent ou indisponible, l'appelant attend ou échoue. Sur une chaîne de cinq services synchrones, la disponibilité globale est le produit des disponibilités individuelles — si chacun est à 99,9 %, la chaîne tombe à 99,5 %.
La communication asynchrone via message broker découple ce couplage. Le producteur publie un message dans un topic Kafka ou une queue RabbitMQ et continue son travail. Le consommateur traite le message quand il est disponible. Les avantages : résilience naturelle, scalabilité indépendante, possibilité de rejouer les messages. Les inconvénients : complexité de gestion du broker, latence éventuelle, cohérence finale plutôt qu'immédiate, gestion des messages en double (idempotence).
gRPC offre une troisième voie pour la communication synchrone à hautes performances : protocole binaire (Protocol Buffers), fortement typé, avec génération de code client/serveur. Il est particulièrement adapté aux communications inter-services internes où la performance prime. GraphQL excelle pour des besoins de composition de données flexibles côté client. En pratique, une architecture microservices mature utilise souvent les deux modes : synchrone pour les requêtes utilisateur nécessitant une réponse immédiate, asynchrone pour les traitements métier différés.
- REST/gRPC pour les opérations nécessitant une réponse immédiate
- Kafka/RabbitMQ pour les processus métier découplés
- Rendez vos consommateurs idempotents
- Documentez les contrats de messages comme les API REST