Message Queues & Pub/Sub — Part 2: Broker Internals and Delivery Semantics

maang.io System Design Series

What is this?

Back to the kitchen. In Part 1 the ticket rail was a tidy abstraction — drop a ticket, a cook grabs it. But run a real restaurant and the rail sprouts hard questions. What if the rail catches fire — do we lose every pending order? What if a cook grabs a ticket, then collapses before plating the dish — does that order vanish, or does someone else pick it up? What if two cooks grab the same ticket? What if tickets must be cooked in order — appetizers before mains? And what happens to the one ticket nobody can ever cook because the handwriting is illegible?

These aren't edge cases. They are the entire engineering substance of a message broker. A toy queue is a hundred lines of code; a production broker is a master's thesis in distributed systems, and almost all of it is dedicated to answering exactly those questions: durability, acknowledgment, delivery guarantees, and ordering.

The one-line idea: the broker's real job isn't "holding messages" — it's making promises about them (this message won't be lost; it'll be delivered at least once; these messages stay in order) and the strength of each promise costs you something in latency, throughput, or complexity.

This part is the machine room. We'll open the broker, examine what an "ack" actually guarantees, work through the three delivery semantics, and then meet the two great architectural lineages that dominate the field: the log (Kafka) and the traditional broker (RabbitMQ/SQS).