Skip to content
Software Architecture Guide

Dynamic Router

Explanation

Section titled “Explanation”

A router decides where each message goes. A simple router knows every possible destination in advance. That creates a dependency: the router must change whenever destinations change. The Dynamic Router addresses this. It aims to remove the dependency while keeping routing efficient.

How it works. Besides the usual input and output channels, the pattern adds a control channel. Recipients use it to tell the router about themselves. The router stores each participant’s preferences in a rule base, which is a collection of conditions. It routes a message to the recipient whose rules are fulfilled.

In Apache Camel. Camel offers a Dynamic Router component. It builds its rule base while the system runs. It updates that rule base as participants subscribe or unsubscribe through the control channel. A recipient can leave by sending an unsubscribe message.

The component keeps prioritized filters for each channel. A recipientMode option, either firstMatch or allMatch, decides what happens when several recipients match one message.

Camel also has a core Dynamic Router, which is a separate implementation with no control channel. It computes the route at runtime. It is similar to a Routing Slip (see the Routing Slip article), except that the slip is evaluated dynamically. For some use cases the core version fits better.

In Spring Integration. Its documentation describes the pattern as a way to change router configuration without bringing down the system. Mapping routers let you add, change and remove channel mappings at runtime. You can expose these operations through JMX or the control bus.

Example

Section titled “Example”

An order system sends messages to several handlers. A new “gift-card” handler starts up. It sends a registration message on the control channel, along with the conditions it accepts. The router adds these to its rule base. Later orders that match go to the new handler. Nobody edited the router’s code. When the handler is retired, it sends an unsubscribe message and the router drops its rules.

Trade-offs

Section titled “Trade-offs”

Benefit: the router no longer depends on a fixed list of destinations. Recipients can join and leave while the system runs.

Cost: consistency. In Spring Integration, changing the routing table step by step is not atomic. Removing one route and adding another can leave the table briefly in an indeterminate state. Since version 4.0, you can replace the whole table atomically.

Cost: choice of variant. Camel’s component adds a control channel, but the core pattern has none. Pick the one that matches your use case.

Cost: overlapping rules. When several recipients match, you must decide between first match and all matches, and set filter priorities.

Recipients register rules over the control channel. The router uses its rule base to route input messages.

Diagram source 
flowchart LR
  R1[Recipient A] -.register + rules.-> C((Control channel))
  R2[Recipient B] -.register + rules.-> C
  C --> Router[Dynamic Router\nrule base]
  In[Input channel] --> Router
  Router --> R1
  Router --> R2

Checks

Section titled “Checks”
  • The document states whether the design uses a control channel for recipients to register and unsubscribe.
  • The document says how the router handles a message that matches several recipients, for example first match or all matches.
  • The document states whether routing-table changes at runtime are applied incrementally or replaced as a whole, and how inconsistency is handled.
  • The document says whether the core Dynamic Router or Camel’s component is used, if Camel is the technology.
Section titled “Related”

Sources

Section titled “Sources”