Queues & Lastglättung

The last building block of scalable design is the message queue - the shock absorber that sits between parts of a system so they don't have to move in lockstep. You met queues in the Spring messaging module; here we see why they're a load-bearing tool in system design. A queue decouples a producer from a consumer, absorbs spiky load so a burst doesn't topple a downstream service, and lets slow work happen asynchronously off the request path. It's how a system survives a traffic spike gracefully instead of falling over.

Decoupling: producers and consumers move independently

Without a queue, a producer calls a consumer directly and synchronously - so the producer's speed is chained to the consumer's, and if the consumer is down, the producer fails too. A queue breaks that chain: the producer drops a message on the queue and moves on; the consumer picks it up when it's ready.

Synchronous (coupled):   Producer ──calls──► Consumer   (producer waits; consumer down = producer fails)

Queued (decoupled):      Producer ──►[ Queue ]──► Consumer
                         (producer returns immediately; consumer processes at its own pace)

This decoupling (the same benefit as domain events, now at infrastructure scale) means the two sides can be scaled, deployed, and fail independently. Add more consumers to process faster; the producer neither knows nor cares.

Load-leveling: the queue as a buffer

The killer feature for scale is load-leveling (a.k.a. the queue-based load-leveling pattern). Real traffic is spiky - a flash sale, a viral moment, a nightly batch - and a synchronous system must be provisioned for the peak or it collapses under it. A queue turns spikes into a steady stream:

Bursty arrivals:   ▁▁█████▁▁▁███████▁▁   (producers, wildly variable)
                          │
                     [  Queue  ]  ← absorbs the burst; depth grows then drains
                          │
Steady processing: ▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃▃   (consumers, provisioned for AVERAGE, not peak)

The consumer processes at its own steady rate; when arrivals exceed that rate, the queue simply gets deeper and drains later. You provision consumers for the average load, not the terrifying peak - a huge cost saving and a guarantee that a spike causes delay, not failure. The queue depth is your buffer, and it's also a signal: a persistently growing queue means consumers can't keep up and you need to scale them.

Back-pressure: when the buffer isn't infinite

Queues aren't magic - if producers permanently outpace consumers, the queue grows without bound and eventually you're out of memory or storage. Back-pressure is the system's way of signaling "slow down": bounded queues that reject or block producers when full, so overload is handled deliberately (shed load, return a 429) rather than by silently exhausting resources and crashing. A queue smooths temporary spikes; back-pressure protects against a sustained overload the system genuinely can't handle. (Recall reactive streams - back-pressure was their whole point.)

Delivery guarantees and idempotency

Queues introduce the delivery-semantics question from the messaging and batch modules:

• At-most-once - a message might be lost, never duplicated. Rarely acceptable.
• At-least-once - a message is never lost but may be delivered more than once (a consumer crashes after processing but before acknowledging, so it's redelivered). The common, practical default.
• Exactly-once - the ideal, but very hard and expensive in a distributed system; usually simulated by at-least-once + idempotent consumers.

Because at-least-once means duplicates, consumers must be idempotent - processing the same message twice has the same effect as once (the idempotency-key idea from the API module, applied to messages). This is the single most important rule of queue-based systems: design consumers to tolerate duplicates. Related patterns: a dead-letter queue for messages that repeatedly fail (so one poison message doesn't block the queue).