Dynamic Router
The router that does not know where to dispatch — it asks consumers and learns.
Problem
A classic Content-Based Router has its rules hard-coded. How to evolve when adding a new partner or message type without redeploying the router?
Forces
- Routing must change without restarting the central hub.
- Consumers know their capabilities better than the central router does.
- Capabilities evolve — schema versions, new subsets, protocol deprecations.
- Hard-coding inevitably leads to stale rules nobody dares to touch.
Solution
Each consumer emits an announcement message on a control channel: "I can process EDIFACT INVOIC D.96A, I can process X12 850 v4010". The router indexes these announcements in an in-memory table and routes accordingly. Periodic re-announce (heartbeat) handles disappearances.
EDI implementation
In EDI, the Dynamic Router is useful for multi-tenant SaaS hubs where partners are configured via API. Each consumer service (EDIFACT parser, X12 validator, AS2 server) publishes a JSON capability description on an edi.control.announce topic. The router consumes this announcement and indexes it. Advantage: adding a consumer = no central change.
Anti-patterns
- No heartbeat — a crashed consumer stays in the table, messages lost.
- No announcement versioning — a schema-breaking deployment breaks everything.
- Free-text announcements — impossible to index reliably.
Related patterns
- Content-Based Router — static version.
- Message Router — parent concept.
- Control Bus — announcement channel.
Sources
- Hohpe G., Woolf B. — EIP, Dynamic Router (p. 243). www.enterpriseintegrationpatterns.com/patterns/messaging/DynamicRouter.html