Apps talk to each other by sending messages. But there are two very different ways to deliver them. A Queue hands each message to one worker. A Topic broadcasts each message to everyone who's listening. That single difference changes everything — let's see it move.
Press Send a message. The same message goes into both systems at once. Watch where it ends up — and count who receives it.
Workers compete for messages. Each message is grabbed by just one worker, then it's gone. Great for splitting up jobs.
Every subscriber gets its own copy of every message — and the messages are kept in a log you can re-read later.
Same idea, no code. These two everyday things behave exactly like a Queue and a Topic.
Neither one is "better." They're built for different jobs. Here's the honest scorecard.
Answer these three questions about your project. The needle will lean toward the better fit as you go.
1. Should each message be done by just one worker, or does everyone need it?
2. Do you need to keep old messages and replay them later?
3. Is your project more about sharing out tasks, or streaming lots of events?
Real situations you can picture. Notice how "one worker" vs "everyone gets it" decides the winner.
1,000 orders come in. Each email should be sent once. Share the load across 5 email workers so no customer gets two emails and none get missed.
Users upload pictures that each need shrinking. Drop each job in the queue; whichever worker is free grabs the next photo. Pure task-sharing.
One "new video" event, but the search index, the recommendation system, and the notification service all need to know. Broadcast it once; each subscriber reacts its own way.
A firehose of "user did X" events. Keep the full history so teams can replay it, build charts today, and re-run new analysis on old data next month.
Three quick questions. Tap an answer to see if you've got it.