Datatype Channel
Un canal, un type — la règle qui rend les consumers prévisibles et le routage simple.
Problème
Si une queue mélange Order, Invoice et Despatch Advice, chaque consumer doit inspecter le type avant de traiter — duplication de logique, risque d'erreur.
Forces
- Les consumers veulent un type connu pour pouvoir le typer en code (TypeScript, Kotlin, Go).
- Le throughput d'une queue dépend du parallélisme — séparer les types permet d'allouer plus de partitions au flux le plus chargé.
- Le monitoring est plus lisible quand un topic = un type métier (latence ORDERS distincte de latence INVOIC).
- Le routage est plus simple — pas besoin de filter sur header.
Solution
Créer un canal par type de message — edi.orders, edi.invoices, edi.despatch-advices, edi.mdns. Chaque consumer s'abonne au(x) topic(s) qui le concernent. Le typage du payload est garanti par schéma (Avro, JSON Schema, Protobuf) enregistré dans une Schema Registry.
Implémentation EDI
En EDI, le Datatype Channel implique : un topic Kafka par type métier (10-15 topics typiquement), un schéma Avro versioné dans Apicurio Registry, des partitions par partner_id pour la scalabilité. Le pattern paye sur le débogage : voir 'topic edi.mdns lag = 12 secondes' est immédiatement actionnable, alors qu'une queue mixte aurait masqué le problème.
Anti-patterns
- Un topic edi.everything qui mélange tous les types — anti-pattern certain.
- Trop de topics (un par sous-type, par partenaire, par direction) — explosion combinatoire et complexité opérationnelle.
- Pas de schéma enforced — les producteurs envoient n'importe quoi, les consumers crashent.
Patterns liés
- Message Channel — concept parent.
- Canonical Model — modèle de données pivot.
- Invalid Message Channel — canal pour messages malformés.
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