Control Bus
The admin channel parallel to the business channel — manage components hot.
Problem
How to control a distributed EDI hub hot — restart a parser, drain a queue, disable a broken partner, without redeploying?
Forces
- Mixing control and data pollutes both flows.
- Control must be audited (who restarted what?).
- Control must be typed (cannot send a malformed command).
- Components must be able to refuse a command (security, incompatible state).
Solution
Define a Control Bus distinct from business channels — typically an edi.control Kafka topic or a dedicated broker. Components subscribe to it on top of their business channel. Typed messages (StartCommand, StopCommand, ReloadConfig, HealthCheck, MetricsRequest). Strict RBAC — only authorised operators can publish.
EDI implementation
In EDI, Control Bus is used to: reload mappings without restart, pause/resume a partner during maintenance, trigger metrics dumps, run selective replays. Implementation: edi.control Kafka topic with typed JSON messages, subscribed via the same framework (Camel, Spring Cloud Stream) but with separate ACL.
Anti-patterns
- Open Control Bus without auth — anyone can take down the hub.
- Long-running synchronous control — blocking the conversation during a health check.
- No audit logs — impossible to trace who did what.
Related patterns
- Dynamic Router — classic Control Bus consumer.
- Test Message — message via Control Bus.
- Channel Purger — action triggered via Control Bus.
Sources
- Hohpe G., Woolf B. — EIP, Control Bus (p. 540). www.enterpriseintegrationpatterns.com/patterns/messaging/ControlBus.html