Message queues

What a point-to-point queue actually buys you

A message queue is a durable buffer between two parties. A producer appends a message; the queue persists it; a consumer pulls it later, processes it, and acknowledges. “Point-to-point” means each message is delivered to one consumer in the group and then removed — contrast that with the fan-out of pub/sub in the next lesson, where every subscriber gets a copy. The defining property is temporal decoupling: the producer and consumer no longer have to be alive, fast, and reachable at the same instant.

That single property buys three things at once. Load levelling — a spike of 10,000 enqueues doesn’t have to be processed at 10,000/sec; the queue absorbs the burst and the consumer drains it at its sustainable rate. Failure isolation — if the consumer crashes, messages wait in the queue instead of erroring back to the producer; the work resumes when the consumer recovers. Independent scaling — you scale producers and consumers separately, adding consumer instances to drain faster without touching the producer.

The senior framing is that a queue converts a synchronous availability dependency into an asynchronous latency dependency. Synchronously, your availability is the product of every downstream’s availability — three 99.9% services in a call chain give you 99.7%. Put a durable queue between them and the producer’s success no longer depends on the consumer being up; it depends only on the queue being up. You’ve traded “the whole request fails when email is down” for “the receipt arrives a few minutes late.”

The honest delivery semantics: at-least-once vs at-most-once

Here is the part juniors skip and seniors design around. A queue and its consumer talk over an unreliable network, and the consumer can crash at any point. That forces a choice about when you acknowledge a message, and the choice fixes your delivery guarantee:

at-most-once   ack BEFORE processing → if the worker crashes mid-process,
               the message is gone. No duplicates, possible loss.

at-least-once  ack AFTER processing → if the worker crashes after the work
               but before the ack, the message is redelivered. No loss,
               possible duplicates.

There is no third honest option over an unreliable network. You either risk losing a message (ack early) or risk processing it twice (ack late). Nearly every durable queue — SQS, RabbitMQ, classic JMS — defaults to at-least-once, because for most systems a duplicate is recoverable but a lost order is not. The consequence you must internalize: your consumer will, eventually, see the same message twice. Design as if it’s guaranteed, because at scale it is.

”Exactly-once” is effectively-once: idempotency + dedup

When a vendor sells “exactly-once,” they mean effectively-once: the message may be delivered more than once, but its effect happens once. You get there with two tools working together. Idempotency — design the operation so applying it twice equals applying it once: set balance = 100 is idempotent; add 100 to balance is not. Deduplication — give each message a stable business key (an order ID, a payment intent ID) and keep a record of keys you’ve already processed; on redelivery, you see the key, skip the work, and just re-ack.

producer: enqueue { idempotency_key: "order-8842", action: "charge $50" }

consumer on each delivery:
  if seen("order-8842"):  ack and stop      ← dedup catches redelivery
  else:                   charge, mark seen("order-8842"), ack

The dedup store (a row with a unique constraint, a Redis key with a TTL) is what turns at-least-once delivery into effectively-once processing. This is why the right mental model is never “I’ll find a queue that won’t duplicate.” It’s “I’ll accept duplicates at the door and make them harmless inside.” Effectively-once is a property of your code, not a checkbox on the broker.

The mechanics that make at-least-once work: visibility timeout, DLQ, ordering

Three mechanisms turn the theory into a running system:

• Visibility timeout. When a consumer pulls a message, the queue doesn’t delete it — it hides it for a configured window. If the consumer finishes and deletes it within the window, done. If the consumer crashes (never deletes), the timeout expires and the message reappears for another worker. This is how at-least-once redelivery actually happens. Set it too short and a slow-but-alive worker’s message reappears and gets processed twice; set it too long and a genuinely crashed message takes ages to retry. Long jobs must heartbeat — extend the timeout while still working — or the queue will hand the same message to a second worker and you get parallel duplicate processing.
• Dead-letter queue (DLQ). A message that fails repeatedly (a “poison” message — malformed input, a bug) would otherwise be redelivered forever, burning capacity and blocking the queue. After N failed attempts the broker moves it to a separate dead-letter queue for human inspection. Alarm on DLQ depth: a non-empty DLQ means a bug, not a transient blip.
• Ordering. A plain queue with many parallel consumers makes no global ordering promise — message B can finish before message A. If you need order, you need ordering per key (SQS FIFO message groups, a single partition), which costs throughput because messages in one group can’t be processed in parallel. Most systems don’t need global order; they need order within a single entity (one user’s events) and design the key accordingly.

This unit stays at system-composition altitude — where a queue sits in an architecture and what guarantee it changes. The dedicated queues track goes a level deeper into the brokers themselves: how SQS, RabbitMQ, and Kafka implement delivery, the exact ack protocols, and broker tuning. Reach for it when you’re configuring a specific broker; stay here when you’re deciding whether a queue belongs in the design at all.