Message Queues

Imagine two people trying to hand each other a package. They both have to be in the same place, at the same time, and one has to wait while the other is ready. If one person is busy, the other just stands there, package in hand, doing nothing.

Now imagine a post office between them. Person A drops off the package whenever they want and walks away. Person B picks it up whenever they're ready. They never need to meet. They never need to coordinate schedules. They don't even need to know each other exists.

That post office is a message queue. And it's one of the most important patterns in distributed systems.

Every large-scale system uses message queues. Amazon processes millions of orders through SQS. Uber dispatches rides through Kafka. Netflix decodes video through their own queue infrastructure. The reason is always the same: when one service produces work faster than another can handle it, you need a buffer in between.

Without that buffer, the fast service either waits (wasting resources) or the slow service gets overwhelmed (dropping requests). Neither is acceptable at scale.

A message queue has three actors:

• Producer: the service that creates messages and pushes them onto the queue
• Queue: the buffer that stores messages until they're consumed
• Consumer: the service that pulls messages off the queue and processes them

The queue guarantees that every message is delivered to exactly one consumer (in a simple queue setup). Messages are typically processed in FIFO order, first in, first out, though some queues support priority ordering.

The key properties:

• Decoupling: Producers and consumers don't know about each other. You can replace, scale, or restart either side without affecting the other.
• Buffering: If the consumer is slow or temporarily down, messages accumulate in the queue instead of being lost.
• Load leveling: A sudden spike of 10,000 messages doesn't crash your consumer. It just means the queue gets deeper, and the consumer works through it at its own pace.

Think of a restaurant kitchen. Waiters (producers) place order tickets on a rail (queue). Cooks (consumers) pull tickets and prepare food at their own speed. The rail decouples the dining room from the kitchen. If 20 tables order at once, the tickets pile up on the rail, but nobody crashes.

A concrete example with numbers. Your checkout service handles 500 orders per second at peak. Each order triggers an email, a PDF receipt, and an inventory update. Those three tasks take 2 seconds combined. Without a queue, checkout blocks for 2 seconds per order and can only handle 1 order per 2 seconds. With a queue, checkout publishes a message in 5ms and returns. The email, PDF, and inventory workers drain the queue at their own pace. Checkout throughput: 500/s. Worker throughput: whatever you scale the pool to.