Pub/Sub Fan-Out
One event, many listeners — and why persistence matters.
A queue delivers each message to exactly one worker. Publish/subscribe (pub/sub) is the opposite shape: one event goes to every subscriber of a topic. It is the backbone of real-time fan-out — routing a chat message between servers, or telling three different services that "video uploaded."
In the animation, a megaphone publishes one message that clones into three copies, flying to three subscribed servers at the same instant. That simultaneity is the point: nobody waits in line.
Then comes the catch. A fourth server is asleep when the megaphone fires — and it simply misses the message. Plain pub/sub (like Redis pub/sub) is fire-and-forget: if a subscriber is offline, the message is gone. This is called at-most-once delivery.
The fix appears next: a database icon upstream of the megaphone, showing the message safely persisted before publishing. Durability comes from the database write; pub/sub only provides the fast real-time push. The sleeping server reads what it missed from the database when it wakes.
This "persist, then publish" pattern is the key move in chat-system interviews: user A is connected to server 1, user B to server 2, and pub/sub is how the message crosses — but the inbox table is why it is never lost.