Content-Based Router

A Content-Based Router is a specialization of the Message Router that decides where to send a message by examining its content — fields, headers, or body values. A single input channel can carry many message variants, and the router dispatches each to the handler that knows how to process it.

The problem it solves is mixed-traffic dispatch. Often messages of different types or destined for different processing arrive on one channel because the producer cannot or should not distinguish them. The content-based router reads each message and applies rules to pick the correct output channel.

How It Works

The router defines an ordered list of predicates, each mapped to an output channel. For each incoming message it evaluates predicates against the content — for example, a JSON field type, an XML element, or a numeric threshold. The first matching rule wins, and the message is forwarded unchanged. A default or invalid-message channel typically catches anything that matches no rule.

Good implementations avoid hardcoding rules in code where possible, expressing them in configuration or a rules engine so routing can evolve without redeployment.

if amount > 10000 -> queue.review
else if region == 'EU' -> queue.eu
else -> queue.default

When to Use It

Use it when one channel carries heterogeneous messages and routing depends on payload, when adding a new message variant should only require a new rule and handler, or when you want to keep producers oblivious to consumer topology. It is common at the edge of microservice systems and in ESB-style integrations.

Avoid putting heavy business logic in the router; it should decide direction, not perform work.

Trade-offs

The router must understand message content, which couples it to the payload schema. Schema changes can break routing, so version messages and validate them. Deep content inspection can be costly at high throughput. Centralizing rules aids maintainability but risks creating a brittle, sprawling decision table; keep rules cohesive and well tested.

Related Patterns

It is a kind of Message Router. A Message Filter drops non-matching messages instead of routing them elsewhere. A Normalizer often precedes it to canonicalize varied formats before routing. A Recipient List handles the multi-destination case.

Example

A Spring Integration flow inspects the documentType header and routes INVOICE messages to the billing service channel and RECEIPT messages to the archival channel, with unrecognized types going to a manual-review channel.