Pub/sub vs queues

A customer places an order. The email service needs to know, so it can send a confirmation. Analytics needs to know, so the dashboards update. The warehouse service needs to know, so someone packs a box. The loyalty service needs to know, so points get added. One thing happened, and four different parts of your system care.

The previous unit gave you the queue: put a message in, one worker takes it out, the work happens later. But look what happens if you push the order event into one queue that all four services read from. A queue delivers each message to exactly one consumer. The email service grabs it, and analytics, warehouse, and loyalty never hear about the order at all. Three quarters of your system is now silently broken, and the queue is working exactly as designed.

The mismatch is that a queue answers "who does this task?" while this situation asks "who needs to hear this news?" Those are different questions with different tools. This unit teaches you to tell them apart on sight, because interviewers plant this fork inside almost every design prompt.