# Asynchronous Messaging

> Use asynchronous messaging channels for inter-service communication in event-driven systems.

- **Category**: Event Driven Architecture
- **Subcategory**: core
- **Canonical URL**: https://designpattern.fyi/patterns/event_driven_messaging/

---

## Description
**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.

**Problem**: How do services in an event-driven microservice architecture communicate?

**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).



## Use Cases
Use when services need to communicate asynchronously, especially in event-driven architectures where loose coupling and resilience are priorities.





## Trade-offs


### 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




### Considerations & Drawbacks

- 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







---
**Reference**: [Original Source](https://microservices.io/patterns/communication-style/messaging.html)