As your event-driven architecture grows, you’re going to hit a point where not every consumer needs every message. You’ve got events flowing through your system, but different consumers care about different things. So how do you get the right message to the right place?

This is where the content-based router comes in. It’s a pattern I first came across in the Enterprise Integration Patterns book, and honestly, many of us are already doing some version of this without even knowing the name.

What is it?

• A content-based router reads the content of a message/event and decides where to send it based on rules you define.

• Think of it like an if/else or switch statement, but at the messaging infrastructure level rather than inside your application code.

• The router doesn’t change the message, it inspects it and forwards it to the right channel or consumer.

• Example: an order event comes in. If the item type is “electronics” it goes to one service, if it’s “clothing” it goes to another. The router looks at the content and makes that decision for you.

You’re probably already doing this

Many folks building on modern brokers are already doing content-based routing without calling it that.

• EventBridge rules - If you’re using Amazon EventBridge, those event rules that match on event content and route to targets? That’s content-based routing. You’re inspecting the event payload and deciding where it goes.

• SNS message filtering - When you set up filter policies on SNS subscriptions based on message attributes, you’re routing based on content.

• Kafka consumers with conditional logic - If your consumer reads a message, checks a field, and decides whether to process it or skip it, you’ve pushed the routing into the consumer. It works, but it means every consumer has to receive and inspect every message.

• SQS with EventBridge Pipes - You can filter and route messages between queues based on content using Pipes, another form of this pattern.

Sounds simple right? The pattern itself is straightforward, but the decisions around where to put the routing logic and how to manage the rules… that’s where it gets interesting.

Routing at the broker vs routing in the consumer

This is something worth thinking about. You have two choices:

• Route at the broker/infrastructure level - The router sits between the producer and consumers. Only relevant messages reach each consumer. Consumers stay focused on their own concern.

• Route inside the consumer - Every consumer receives every message and decides internally what to process. This can work for small systems but gets noisy fast.

I generally favour routing at the broker level when you can. It keeps consumers clean, reduces unnecessary processing, and means your consumers don’t need to know about message types they don’t care about. But it does mean your routing rules live outside your application code, which can make them harder to discover and test. Trade-offs everywhere.

What happens when nothing matches?

This is something many people overlook. You define your routing rules for the cases you know about, but what happens when an event comes through that doesn’t match any rule?

• Does it get silently dropped? That’s dangerous. You might not notice for days.
• Does it go to a dead letter queue or an invalid message channel?
• Do you have alerting in place?

Without thinking about the “no match” scenario you can easily end up with lost messages and no idea why. It’s worth designing for this from day one. A catch-all route that sends unmatched messages somewhere visible is a good practice.

Content-based routing with other patterns

This pattern works really well when combined with others:

• Splitter + Content-Based Router - Split a large message into parts, then route each part to the right consumer. This is a really common combination. Example: split an order into individual items, then route each item to the correct fulfilment service based on product type.

• Content-Based Router + Message Translator - Route to the right destination, then translate the message into the format that destination expects. Keeps your routing clean and your translations isolated.

• Content-Based Router + Content Enricher - Sometimes you need to enrich a message before you can route it. The data you need for the routing decision might not be in the original event.

Things to consider

• Keep routing rules manageable - It’s tempting to add more and more rules over time. Before you know it you’ve got 50 routing rules and nobody knows why half of them exist. Document them, review them periodically.

• Routing logic is business logic - The rules you define reflect real business decisions. Treat them with the same care you’d treat any business logic. Who owns them? How do you change them? How do you test them?

• Think about discoverability - If an event can end up in five different places depending on its content, how does someone new to your team figure that out? This is where documenting your architecture really matters.

• Consider the coupling - Your router needs to understand the message structure to inspect it. If that structure changes, your routing rules might break. Be mindful of what fields you route on and how stable they are.

Extra Resources

• Content-Based Router from Enterprise Integration Patterns - The original pattern that inspired this visual. Well worth reading if you want the full picture.
• Splitter Pattern - Often paired with content-based routing. Split first, then route each part.
• Message Translator Pattern - Route to the right place, then translate into the format consumers expect.
• Content Enricher Pattern - Sometimes you need more data before you can make a routing decision.
• Amazon EventBridge content-based filtering - A practical implementation of content-based routing using EventBridge rules.