Datatype Channel
One channel, one type — the rule that makes consumers predictable and routing simple.
Problem
If a queue mixes Order, Invoice and Despatch Advice, each consumer must inspect the type before processing — duplicated logic, error-prone.
Forces
- Consumers want a known type to type-check the code (TypeScript, Kotlin, Go).
- Queue throughput depends on parallelism — separating types allows more partitions on the heaviest stream.
- Monitoring is more readable when one topic = one business type (ORDERS latency distinct from INVOIC latency).
- Routing becomes simpler — no need to filter on header.
Solution
Create one channel per message type — edi.orders, edi.invoices, edi.despatch-advices, edi.mdns. Each consumer subscribes to the topic(s) it cares about. Payload typing is enforced via a schema (Avro, JSON Schema, Protobuf) registered in a Schema Registry.
EDI implementation
In EDI, Datatype Channel means: one Kafka topic per business type (typically 10-15 topics), a versioned Avro schema in Apicurio Registry, partitioning by partner_id for scalability. The pattern pays off in debugging: seeing "topic edi.mdns lag = 12 seconds" is immediately actionable, whereas a mixed queue would have hidden the issue.
Anti-patterns
- An edi.everything topic mixing all types — certain anti-pattern.
- Too many topics (one per sub-type, partner, direction) — combinatorial explosion and operational complexity.
- No enforced schema — producers push anything, consumers crash.
Related patterns
- Message Channel — parent concept.
- Canonical Model — pivot data model.
- Invalid Message Channel — channel for malformed messages.
Sources
- Hohpe G., Woolf B. — EIP, Datatype Channel (p. 111). www.enterpriseintegrationpatterns.com/patterns/messaging/DatatypeChannel.html
- Confluent — Schema Registry overview. docs.confluent.io/platform/current/schema-registry/index.html