We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Messaging Event Systems
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Messaging Event Systems
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Your email inbox gets hundreds of messages a day. Without filters, you'd read every single one to decide if it's relevant. Instead, you set up rules: sales alerts go to a folder, newsletters get archived, messages from your boss get flagged.
Message filters work the same way for queues and topics. Instead of delivering every message to every consumer and letting the consumer decide what to keep, the broker evaluates a filter expression and only delivers matching messages. The consumer never sees messages it doesn't care about.
Why does this matter? Because receiving, deserializing, inspecting, and discarding irrelevant messages wastes CPU, memory, and . At scale, the waste becomes absurd. If your order service only cares about messages where region = "US", it shouldn't receive and throw away millions of European order events every hour. The broker should handle that filtering before delivery. Amazon SNS filter policies reduced one team's Lambda invocations by 85% just by dropping irrelevant messages before they hit the function.
Filters are typically applied to message headers or attributes (not the body, which would require full deserialization):
Content-based filtering. The broker inspects message attributes and evaluates a predicate. Only messages matching the predicate are delivered.
-- JMS / RabbitMQ headers exchange
region = 'US' AND amount > 100
-- Azure Service Bus subscription filter
sys.Label = 'important' AND user.region = 'EU'
-- Google Pub/Sub attribute filter
attributes.region = "US"
Topic/routing-key filtering. The producer assigns a routing key, and the consumer subscribes to a pattern. This is RabbitMQ's bread and butter.
orders.*.US matches orders.created.US, orders.shipped.US
orders.# matches any routing key starting with orders
Consumer-side filtering. The consumer receives all messages and discards irrelevant ones in application code. works this way by design: no broker-side filtering, all filtering happens in the consumer or in Kafka Streams.
| System | Filter Mechanism | Where Applied | Overhead |
|---|---|---|---|
| RabbitMQ | Routing keys + header exchanges | Exchange level | Near zero (exchange routing) |
| Kafka | No native filter (consumer-side) | Consumer code | Full message transfer + deser |
| Google Pub/Sub | Attribute filters on subscriptions | Subscription level | Low (evaluated before delivery) |
| Azure Service Bus | -like filters on subscriptions | Subscription level | Low |
| Amazon SNS | Filter policies (JSON) | Subscription level | Low |
| Amazon SQS | No native filter | Consumer code | Full message transfer + deser |