Routing & Fanout

The same event, multiple services#

Suppose one event arrives:

ad.click

And three services want it:

• billing
• fraud
• analytics

How the event reaches all three is very different across the systems.

SQS#

Plain SQS is just a queue:

Producer -> one queue -> one worker flow

If multiple services all need the same event, one queue is wrong because the consumers would compete for the same message.

So AWS usually adds SNS:

Producer -> SNS topic -> billing SQS queue
                     -> fraud SQS queue
                     -> analytics SQS queue

That means SQS alone is not the fanout layer.

RabbitMQ#

RabbitMQ has routing built in:

Producer -> exchange -> billing.queue
                     -> fraud.queue
                     -> analytics.queue

The exchange can broadcast, do exact-key routing, or pattern-based routing depending on exchange type and bindings.

This is why RabbitMQ is called routing-first.

Kafka#

Kafka handles fanout differently:

Producer -> ad-events topic
Billing consumer group reads
Fraud consumer group reads
Analytics consumer group reads

The event sits once in the log, and each consumer group independently reads it.

So Kafka fanout is not "copy to many queues." It is "many groups independently read the same retained event stream."

The clean contrast#

SQS       -> simple queue, fanout usually via SNS or app logic

RabbitMQ  -> exchange routes to one or many queues

Kafka     -> topic is shared history, fanout via multiple consumer groups