# Messaging Gateway

> Hide all messaging plumbing behind a clean domain API — callers never touch the broker.

- **Category**: Integration
- **Subcategory**: Messaging Endpoints
- **Canonical URL**: https://designpattern.fyi/patterns/messaging_gateway/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
NotificationGateway wraps all messaging infrastructure for the notification domain. Application code calls gateway.sendEmailNotification(userId, template, data). Gateway constructs the message, picks the right channel, attaches traceId, and publishes. Application never sees SQS or Kafka.





## Trade-offs


### Advantages

- Application code is clean from messaging infrastructure concerns

- Broker can be swapped without touching business logic

- Gateway is the single place to enforce messaging standards (headers, tracing, serialization)

- Easy to mock in tests — just mock the gateway interface




### Considerations & Drawbacks

- Additional abstraction layer to build and maintain

- Gateway can hide important messaging behaviors from developers

- Overly generic gateways can become kitchen-sink classes

- Debugging requires understanding both the gateway and the broker







---
**Reference**: [Original Source](https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessagingGateway.html)