# Messaging

> Services talk via async message channels — no direct calls, no tight coupling.

- **Category**: Microservices
- **Subcategory**: Messaging & Events
- **Canonical URL**: https://designpattern.fyi/patterns/messaging/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Order placed → message to "orders" topic on Kafka. Inventory Service, Shipping Service, and Email Service each consume independently. If Email Service is down, messages queue up — no lost events, no cascading failure.





## Trade-offs


### Advantages

- Temporal decoupling — sender and receiver don't need to be up simultaneously

- Natural load leveling via message queues

- Publisher doesn't need to know its consumers

- Resilient to consumer failures — messages persist until consumed




### Considerations & Drawbacks

- Eventual consistency — consumers lag behind producers

- More complex debugging (no request/response trace)

- Broker becomes a critical piece of infrastructure

- Message ordering, exactly-once, and schema evolution all need explicit handling







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