Asynchronous Messaging
Use asynchronous messaging channels for inter-service communication in event-driven systems.
Intent & Description
⚠️ Problem
How do services in an event-driven microservice architecture communicate?
📋 Context
You have applied the Microservice architecture pattern. Services must handle requests from the application’s clients. Furthermore, services often collaborate to handle those requests. Consequently, they must use an inter-process communication protocol.
💡 Solution
Use asynchronous messaging for inter-service communication. Services communicate by exchanging messages over messaging channels. A message channel is a logical abstraction for sending and receiving messages. There are two kinds of channels: point-to-point channels deliver messages to exactly one consumer, while publish-subscribe channels deliver messages to all subscribed consumers. The messaging infrastructure handles message delivery, routing, and persistence. Popular implementations include Apache Kafka, RabbitMQ, Amazon SNS/SQS, and Google Cloud Pub/Sub. Messages can be commands (requesting an action) or events (notifying about something that happened).
Real-world Use Case
Source
Advantages
- Decouples services in time—the producer and consumer do not need to be available simultaneously
- Supports both one-to-one and one-to-many communication patterns
- Message brokers provide buffering that absorbs traffic spikes
- Enables retry and dead-letter queue patterns for reliable processing
Disadvantages
- Additional complexity from operating messaging infrastructure
- Messages may be delivered out of order or duplicated
- Debugging asynchronous flows is harder than synchronous request-response
- Eventual consistency requires careful design to handle intermediate states