Message Filter

A Message Filter inspects each message and forwards it only if it meets defined criteria; otherwise the message is discarded. It acts as a one-way gate that removes irrelevant traffic before it reaches a consumer.

The problem it solves is unwanted messages. On a broadcast channel a subscriber often cares about only a subset of events. Rather than process and ignore the rest, a filter rejects them early, saving downstream work and keeping consumer logic focused on messages it actually wants.

How It Works

The filter sits on a channel between producer and consumer. For each message it evaluates a predicate over content or headers. If the predicate is true, the message passes to the output channel; if false, it is dropped. Unlike a router, a filter has a single output — it does not choose among destinations, it only decides pass or discard.

Conceptually a filter is a content-based router with two outcomes where one outcome is the bit bucket. Many brokers offer this directly as a subscription selector, letting the infrastructure filter before delivery rather than in application code.

Input --> [Filter: status == 'ACTIVE'] --> Output
          (non-active messages dropped)

When to Use It

Use it to implement selective consumption on publish-subscribe channels, to reduce load on downstream systems, or to enforce simple admission rules. Broker-side selectors (JMS message selectors, SNS filter policies, RabbitMQ header exchanges) push filtering into the infrastructure for efficiency.

Avoid using a filter where dropped messages actually matter — silent discard can hide problems. If rejected messages need handling, route them instead.

Trade-offs

Filtering reduces noise and downstream cost but discards data silently, which can complicate debugging and auditing. If filter criteria are wrong, messages vanish without trace, so monitor drop rates. Application-side filters waste delivery bandwidth because messages are transmitted before being dropped; broker-side selectors avoid this but are less expressive.

Related Patterns

It is closely related to the Content-Based Router; the difference is single-output discard versus multi-output dispatch. A Wire Tap can capture filtered traffic for inspection. Publish-Subscribe Channels often rely on filters so each subscriber sees only relevant events.

Example

An AWS SNS topic carries all account events; an SQS subscriber attaches a filter policy { "eventType": ["LOGIN_FAILED"] } so a security service receives only failed-login events and never sees successful logins or profile updates.