Choosing between REST, gRPC, Kafka or RabbitMQ is not a matter of trend. It is an architectural choice with lasting consequences on resilience, coupling and scalability.
When two microservices need to exchange data, the first instinct is often a REST call. It is simple, well-known, well-tooled. But synchronous communication creates temporal coupling: if the called service is slow or unavailable, the caller waits or fails. In a chain of five synchronous services, overall availability is the product of individual availabilities — if each is at 99.9%, the chain drops to 99.5%.
Asynchronous communication via message broker decouples this dependency. The producer publishes a message to a Kafka topic or RabbitMQ queue and continues working. The consumer processes the message when available. Advantages: natural resilience, independent scalability, ability to replay messages. Disadvantages: broker management complexity, eventual latency, eventual rather than immediate consistency, handling duplicate messages (idempotence).
gRPC offers a third way for high-performance synchronous communication: binary protocol (Protocol Buffers), strongly typed, with client/server code generation. It is particularly suited to internal inter-service communications where performance is paramount. GraphQL excels for flexible data composition needs on the client side. In practice, a mature microservices architecture often uses both modes: synchronous for user requests requiring an immediate response, asynchronous for deferred business processes.
- REST/gRPC for operations requiring an immediate response
- Kafka/RabbitMQ for decoupled business processes
- Make your consumers idempotent
- Document message contracts just like REST APIs