Routing and topology

Routing is the rule that decides which consumers receive a message after a producer sends it. Producers name what the message is, and the rules sit in the messaging system, outside the producer’s code. Each tool puts the rules in a different place.

RabbitMQ: exchanges and bindings

A RabbitMQ producer publishes to an exchange. Queues attach to the exchange with bindings, and the exchange copies each message into the queues whose bindings match. The exchange type sets how matching works.

Exchange type	Routes by	Shop example
direct	Routing key equals the binding key exactly	order.placed goes only to queues bound with order.placed
fanout	Every bound queue, the routing key is ignored	Every service gets every order event
topic	Routing key against a pattern: * is one word, # is zero or more	Notifications binds order.* and sees order.placed and order.cancelled
headers	Message header values, with x-match set to any or all	Route on region and priority headers

The default exchange is a direct exchange with no name, and every queue is bound to it by its own name, which is how publishing straight to a queue works. If a message matches no queue, RabbitMQ drops it or returns it to the publisher, depending on how the publisher sent it. A topic exchange with only # behaves like a fanout, and one with no wildcards behaves like a direct exchange.

Azure Service Bus: subscription filters

In Service Bus the producer sends to a topic, and each subscription decides what it wants. A new subscription has a default rule that accepts everything. A rule with a filter narrows it. There are three kinds: a Boolean filter, a SQL filter, and a correlation filter that matches properties for equality. Filters read message properties, never the body. Correlation filters are cheaper to run than SQL filters, and Microsoft’s guidance is to keep routing simple and put business decisions in the consuming service. See queue vs topicQueue vs topicA queue gives each message to one consumer, a topic gives every subscriber its own copy.Opens in a new tab for the copy-per-subscriber shape these filters narrow.

Kafka: key and consumer

A Kafka topic has no routing rules of its own. The key chooses a partition inside the topic, which preserves order per key, see partitions, offsets and consumer groupsPartitions, offsets and consumer groupsHow a stream splits a topic into lanes, marks each reader's place, and shares the work among a group.Opens in a new tab. It does not choose a consumer or filter anything. Every consumer group reads the whole topic, so a service that wants only some events skips the rest itself, or the design uses a separate topic per kind of event.

The catch

Routing is configuration in the broker, so mistakes are quiet. A missing binding or a filter that matches nothing does not raise an error in the producer. The message is dropped, or never copied into the subscription, and the producer’s code looks correct. Treat exchanges, bindings and subscriptions as part of the system’s design, declare them in code or deployment scripts, and watch the queues that receive nothing. See brokers and clients in .NETBrokers and clients for .NETFive messaging services a .NET service can talk to, what each is for, and what a raw client leaves to you.Opens in a new tab for the client side.