[10000truths]

Queues fix throughput volatility (not throughput mismatch) at the cost of added latency. If your widget producer is producing 1000 widgets every half-hour and 0 every other half-hour, and your widget consumer needs to consume 100 widgets every six minutes, a 1000-widget queue solves the problem, in exchange for a half-hour increase in end-to-end processing time. But, as the title and article allude, your widget producer and widget consumer still need to process widgets at the same rate on average. The longer the time window needed for those averages to match, the larger your queue needs to be (and the higher the latency).

That's also why queues are inappropriate for addressing traffic spikes caused by market dynamics (celebrity news, sales events etc.). Those dynamics typically occur over the course of several hours, whereas a web request's latency SLA is on the order of several seconds.

[jstimpfle]

I'd like to note that the only latency that gets increased is latency of the backpressure "signal". Shorter queues can never result in items being processed earlier, I don't think so. It will only increase the time they have to wait until they can "enter the system". Or more of those items will be rejected ("lost event").