Skip to content

Fan-Out Exchange

Broker routing primitive — instantiates Topic-Brokered Event Distribution

The broker's routing primitive that copies each published event to every subscriber queue whose topic binding matches — one publish becomes many, decided by topic pattern.

A Fan-Out Exchange is the routing element inside the broker that turns a single publish into one copy per interested subscriber. Its defining move is that duplication is driven by topic bindings over a namespace, not by an address list: subscriber queues bind to a topic or topic pattern (orders.*, sensors.eu.#), and when an event arrives on a matching subject the exchange places a copy on every bound queue. The publisher emits once and knows nothing of the count. This is deliberately not last-mile delivery to a roster of endpoints — the exchange fans out to broker-internal subscriber queues keyed by subject, and what happens between those queues and the consumers (durability, acknowledgement, retries) is other mechanisms' work. It is the primitive that makes "one event, many subscribers" a routing fact rather than an application loop.

Example

A market-data platform publishes a trade tick to the subject trades.NASDAQ.AAPL. Three kinds of subscriber have bound queues to the exchange: a real-time charting service bound to trades.NASDAQ.AAPL, a sector-analytics service bound to the wildcard trades.NASDAQ.*, and a compliance archiver bound to trades.# (everything). One publish arrives; the exchange matches all three bindings and drops a copy on each of the three queues.

The publishing venue did no fan-out itself — it named a subject and emitted once. When a new options-pricing service later binds trades.NASDAQ.AAPL, it simply begins receiving copies; when the charting service unbinds, its copies stop. The exchange's routing table — subjects on one side, bound queues on the other — is the whole of the "who gets a copy" logic, and it lives in the broker, not in the publisher.

How it works

  • Bindings, not addresses. Subscribers register a topic or topic-pattern binding against the exchange; the exchange holds the subject-to-queue routing table.
  • Match on publish. Each incoming event's subject is matched against every binding (exact or wildcard), and a copy is enqueued for each match — this is the fan-out.
  • Choose the delivery mode. The exchange sets whether that copy is best-effort, at-most-once, or handed to at-least-once machinery, and whether per-subject ordering is preserved.
  • Stop at the queue boundary. Its responsibility ends when a copy lands on each bound subscriber queue; storage, acknowledgement, and redelivery downstream belong to other mechanisms.

Tuning parameters

  • Binding granularity — exact subjects versus broad wildcards. Coarser patterns catch more with fewer bindings but risk over-delivery; finer patterns are precise but multiply the routing table.
  • Exchange type — fan-out-to-all versus topic-pattern versus subject-hash routing. This dial is the difference between "everyone bound," "everyone whose pattern matches," and "one shard of consumers."
  • Delivery mode — at-most-once (fire and forget) versus at-least-once (hand off to acknowledgement). Stronger guarantees cost latency and duplicate-handling downstream.
  • Ordering guarantee — per-subject FIFO versus unordered fan-out. Ordering simplifies consumers but constrains parallel routing.
  • Match cost ceiling — how much wildcard evaluation to allow per publish before the routing table is restructured; guards a hot subject from paying for a huge binding set.

When it helps, and when it misleads

Its strength is eliminating application-level fan-out loops and the recipient lists that rot: the publisher's job shrinks to "emit once on a subject," and the audience becomes a routing-table fact that can grow or shrink without touching producers. Topic-pattern binding[1] additionally lets a subscriber express interest in a whole slice of the namespace with one rule.

It misleads when the topic hierarchy is poorly designed. Overly broad wildcards cause over-delivery — subscribers drowning in events they must then filter in code, which pushes work the exchange was supposed to save back onto consumers. Because the exchange only knows subjects, it cannot express "only trades above $1M"; treating a coarse topic binding as if it were a precise filter is the classic error, and it quietly reintroduces the very fan-out cost the mechanism removed. The discipline is to design the topic namespace so that a subscriber's natural interest maps to a binding, and to hand genuinely content-dependent selection to a filter rather than forcing it into the routing key.

How it implements the components

  • fan_out_delivery_semantics — it is the one-publish-to-many mechanism: it decides how many copies are made, to which bound queues, and under which delivery mode (at-most-once vs. handed to at-least-once).
  • topic_namespace — its bindings are expressed against the space of named subjects; the exchange operationalizes the namespace as a routing table of subjects and patterns.

It does not know which subscribers exist or persist that record (that is the Message Broker's subscription registry), filter on message content (Content-Based Subscription Filter), confirm each delivery (Delivery Acknowledgement), or store a copy for an offline consumer (Durable Subscription Queue).

References

[1] A topic exchange routes by matching a message's subject against binding patterns with wildcards (as in AMQP's topic exchange), as opposed to a pure fan-out exchange that copies to every bound queue unconditionally. Both are standard broker routing primitives; the topic variant is what makes namespace-slice subscriptions possible. ↩