Every lesson so far in this domain has covered a concept that shows up across systems — this one is the concrete decision a real team actually has to make, and the honest answer is that the right default is usually the one that requires the least new operational expertise, not the one with the most impressive throughput numbers.
Intermediate
3 min read
Reframing the question: what does this specific need actually require
The wrong way to choose is "which is the most powerful" — Kafka, RabbitMQ, and SQS/SNS are not ranked versions of the same tool, they're built for different shapes of problem, and the right choice follows directly from which properties from the last ten lessons the actual use case genuinely needs.
Need
Best fit
Why
Simple job queue, low ops overhead, already on AWS
SQS
Fully managed, no infrastructure to run, good enough throughput for the vast majority of real workloads
Fan-out to multiple independent AWS services
SNS (often paired with SQS per subscriber)
Managed pub/sub — each subscriber gets its own SQS queue behind the topic
Complex routing logic (topic wildcards, multiple queues off one event)
RabbitMQ
Exchanges and bindings (lesson 3) are purpose-built for exactly this
Very high throughput, need to replay history, multiple independent consumer groups
Kafka
The log-based model (lesson 2) is built specifically for this; nothing here comes for free operationally
The real cost axis nobody puts on the feature comparison chart
Kafka's capabilities (replay, massive throughput, multiple independent consumer groups) come with real operational weight: partition counts and replication factors to plan upfront, consumer-group rebalancing behavior to understand, retention and storage to size and monitor. A small team reaching for Kafka because it's the most commonly discussed option, without an actual need for replay or that throughput ceiling, takes on meaningfully more operational surface area than the problem requires — the same "use the simplest tool that actually satisfies the requirement" principle this curriculum's other infrastructure domains apply constantly.
A concrete worked example: picking for an order-processing system
A team needs: (1) fan the OrderPlaced event out to email, analytics, and fraud-check services independently, and (2) a durable audit log of every order event for compliance review. Requirement (1) alone points toward SNS/SQS or RabbitMQ fanout — straightforward pub/sub, no replay needed. Requirement (2) — a durable, replayable history — is exactly Kafka's actual differentiator, not a "nice to have" feature. The honest answer here is Kafka, specifically because of requirement (2), not because it's the most capable option in the abstract — if requirement (2) didn't exist, SNS/SQS would be the better, simpler choice for requirement (1) alone.
Managed offerings change the operational-cost column, not the architectural one
Confluent Cloud, Amazon MSK, and Amazon MQ (managed RabbitMQ) remove much of the "running the broker yourself" burden from Kafka and RabbitMQ respectively — this narrows, but doesn't eliminate, the operational gap versus SQS/SNS's fully-managed simplicity, and it changes nothing about which tool's underlying model (log vs. routing vs. simple queue) actually fits a given requirement.