Inspect stable message data, headers or context that legitimately belong in the routing decision.
Enterprise Messaging · Message Routing
Content-Based Router
Inspect message content and route to the destination whose rules match. Keep routing rules visible and maintainable because they often become a frequent change point.
How do we handle a situation where the implementation of a single logical function is spread across multiple physical systems?Adapted from Enterprise Integration Patterns under CC BY 3.0. The visualization and explanatory content on this page are original GateSift material.
Original GateSift visualization
How Content-Based Router works
Message content or metadata is evaluated against explicit rules so the integration selects one destination without making the producer know every receiver.
Message + context
Evaluate routing rules
Route A
Route B
Fallback
Evaluate ordered rules and select one route, keeping an explicit fallback for values no rule understands.
Record the selected route and continue processing without leaking routing knowledge back into the producer.
Curated GateSift guidance
When this pattern is a good fit — and when it is not
Use content-based routing when the next destination genuinely depends on message data or metadata and the routing rule belongs in the integration layer rather than in every producer.
- Different message types, tenants, regions or business states need different destinations.
- Routing rules must evolve independently from producers and consumers.
- A clear fallback path can handle messages that match no explicit rule.
- Every message always follows the same route; a fixed channel is simpler.
- The routing decision requires business state that should remain owned by a domain service.
- Rules are so complex that they effectively become an unversioned business rules engine.
Silent fallbackHigh impact
An overly broad default route can hide missing or outdated routing rules.
Rule driftReview
Environment-specific conditions can route identical messages differently if configuration is not controlled.
Branch observabilityReview
Operators need the selected route and rule outcome in correlation-aware telemetry.
- APIM choose policies work well for request-time routing when the decision can be made from request context.
- Logic App Condition or Switch actions are suitable when orchestration owns the decision and downstream actions differ by branch.
- Service Bus subscription filters are preferable when routing can happen at the broker without executing orchestration code.
What this pattern helps you decide
Inspect message content and route to the destination whose rules match. Keep routing rules visible and maintainable because they often become a frequent change point.
Is there an explicit fallback for unknown or newly introduced message variants?
Can operators explain which rule selected the route from logs alone?
Are routing rules configuration, integration logic, or domain logic—and are they owned by the right layer?
Where you may see it
- APIM choose/when
- Service Bus SQL filters
- BizTalk send-port filters
How the analyzers can surface it
- APIM choose branches
- BizTalk filter expressions
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
GateSift support
Where GateSift can surface this pattern
Detection means the source contains direct structural evidence. Signal means the analyzer sees compatible structure but still needs architectural context.
Detection supportedService Bus Topology Visualizer
Detects subscription rules that route topic messages using SQL or correlation filters.
Open toolDetection supportedAPIM Policy Analyzer
Detects choose-based conditional routing and backend selection.
Open toolArchitecture signalLogic App Workflow Helper
Surfaces conditions or switches that route work into different integration branches.
Open toolDetection supportedBizTalk Binding Visualizer
Detects send-port subscription filters that route messages using context properties.
Open toolSource, licence and attribution
The pattern name and selected problem statement are adapted from Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf under CC BY 3.0. GateSift summaries, Azure mappings, analyzer guidance and diagrams are original. No endorsement by the original authors is implied.