Skip to content

Content-Based Subscription Filter

Subscription-filter tool — instantiates Topic-Brokered Event Distribution

Narrows what a subscriber receives by evaluating predicates on each event's content or attributes, so a subscription gets only the messages that actually match its interest.

A Content-Based Subscription Filter attaches a predicate to a subscription and lets through only the events whose content or attributes satisfy it. What distinguishes it from the routing that precedes it is that it selects on the inside of the message — header fields, typed attributes, payload values — not on the topic the message was published to. A subscriber to payments.* can say "only amount > 10000 AND currency = 'USD'," and the broker evaluates that rule per event, delivering the matches and dropping the rest before they ever reach the consumer. Where a topic binding answers "which subject?", the filter answers "which of these, by what they say?" — turning a coarse firehose into exactly the trickle a consumer wants.

Example

An airline operations dashboard subscribes to the broad topic flights.status, which carries every status change across the whole network — far too much to process. Instead of receiving all of it and discarding most in code, the dashboard registers a filter: status = 'DELAYED' AND origin = 'ORD' AND delay_minutes > 30. From then on the broker evaluates each flights.status event against that predicate and forwards only the Chicago departures delayed more than half an hour.

When operations later also wants weather-holds, they widen the predicate to include status = 'WEATHER_HOLD'; the change is a rule edit, not a new integration. And because the team can see how many events the filter admits versus how many it drops, they notice the predicate is now letting through short taxi-delays they don't care about — evidence they feed back into tightening the rule. The subscription's relevance is a dial the subscriber turns, not a fixed pipe.

How it works

  • Predicate over content. The subscriber supplies a selector — a boolean expression over headers, attributes, or payload fields — that defines relevance for its subscription only.
  • Evaluate per event, at the broker. Each candidate event (already routed to the subscriber's topic) is tested against the predicate before delivery, so non-matches never cross the wire.
  • Admit or drop. Matches are forwarded; non-matches are discarded for this subscriber (other subscribers' filters are independent).
  • Expose match rates. The proportion admitted versus dropped is surfaced so the subscriber can tell whether the rule is too tight or too loose and refine it.

Tuning parameters

  • Predicate expressiveness — simple attribute equality versus rich expressions over payload contents. Richer selection is more precise but costs per-event evaluation and can force the broker to parse payloads.
  • Evaluation site — filter at the broker (saves bandwidth, spends broker CPU) versus near the consumer (cheap for the broker, wastes delivery on non-matches). This dial trades where the work lands.
  • Filter strictness — how narrow the predicate is set. Tighter cuts noise but risks silently excluding events the subscriber actually needed; looser is safer but leaks irrelevance.
  • Header-only vs. deep-payload matching — whether the rule may read only declared attributes or reach into the body. Deep matching is powerful but couples the filter to payload schema.
  • Relevance-feedback cadence — how often admit/drop statistics are reviewed to retune the predicate; frequent review keeps subscriptions sharp but is operational overhead.

When it helps, and when it misleads

Its strength is precision without new topics: rather than minting an ever-finer topic hierarchy to approximate every consumer's interest, a subscriber expresses interest declaratively and gets only what matches — the classic content-based selection[1] that keeps consumers from drowning in irrelevance.

It misleads in two ways. A too-tight predicate causes silent exclusion — the subscriber stops receiving events it needed and, because nothing is delivered, may not notice until downstream behavior has already diverged. And deep-payload filters couple the subscription to the message's internal shape, so a schema change can quietly break the predicate. The related misuse is treating the filter as an access control — "they won't see it because their filter excludes it" — when a filter only narrows delivery, not authorization. The discipline is to watch admit/drop rates as evidence, alert on a filter that suddenly admits zero, and keep confidentiality with a policy mechanism rather than a selector.

How it implements the components

  • filter_and_selector_rule — it is the selector: the per-subscription predicate over content and attributes that decides, event by event, what is delivered.
  • subscriber_relevance_feedback_loop — by exposing what the rule admits versus drops, it gives the subscriber the signal to tighten or loosen its predicate over time, closing the relevance loop.

It does not perform the topic fan-out that gets events to the subscription in the first place (Fan-Out Exchange), decide who is *allowed to receive a topic (Access-Controlled Topic), or define the schema of the fields it reads (Schema Registry).*

Notes

A content filter narrows delivery, never visibility. If an event must not reach a party for confidentiality reasons, that belongs to Access-Controlled Topic; a subscriber whose filter merely excludes an event can widen the filter and see it. Keeping "what I want" (filter) separate from "what I may see" (authorization) is the boundary that stops a convenience feature from being mistaken for a security control.

References

[1] Content-based selection — evaluating a predicate against a message's attributes or body to decide delivery, as with JMS message selectors or a content-based router. It selects on what the message contains, in contrast to routing that selects on the topic it was published to. ↩