Back to Catalog
Integration
Message Channels
Datatype Channel
One channel, one message type — strong typing enforced at the channel level.
Intent & Description
Real-world Use Case
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.
Source
📌 TL;DR
Datatype Channel = one type per channel. No format guessing, no type branching. Channel name IS the type contract. Great for strong typing, watch out for channel sprawl.
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
Disadvantages
- 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