# Datatype Channel

> One channel, one message type — strong typing enforced at the channel level.

- **Category**: Integration
- **Subcategory**: Message Channels
- **Canonical URL**: https://designpattern.fyi/patterns/datatype_channel/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
E-commerce event streams — separate Kafka topics for order.placed, order.shipped, order.cancelled, payment.processed, payment.failed. Each service subscribes only to the topics it cares about. Shipping service never sees payment events. Payment service never sees shipping events.





## Trade-offs


### Advantages

- Consumers know the exact schema without format inspection

- Channel name serves as self-documenting type declaration

- Simpler consumer logic — no type-branching code needed

- Schema evolution per channel is independent of other channels




### Considerations & Drawbacks

- Channel proliferation — one type per channel can create dozens or hundreds of channels

- Discovery and governance of many channels requires good tooling (schema registry, catalog)

- Cross-cutting queries across types require aggregation of multiple channels

- New message types require new channel creation and configuration







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