When is a queue the answer?

A queue is a promise to do the work later. That sentence contains both the entire value and the entire risk, and teams tend to price only one side of it.

What does the queue actually buy?

Three things, and they are distinct. Absorption: bursts arrive faster than you can serve them, and the queue is a reservoir that converts a spike into a backlog. Decoupling: producer and consumer can deploy, fail and scale separately, the boundary hiding a real decision. And retry semantics: work that fails can be redriven without involving the user who requested it.

If your situation contains none of the three, the queue is overhead with a dashboard: an extra hop, an extra failure mode, an extra thing on call. "We might need to scale the consumer independently someday" is not one of the three. Someday can install the queue when it arrives.

What would have to be true for the queue to be the bottleneck?

Usually three things, and teams check one. The broker itself is rarely the limit; well-run brokers move volumes most businesses never see. The limits live at the edges: consumer throughput (the queue is a reservoir, not a pump; if consumers drain slower than producers fill, the backlog grows until something states a policy), poison messages (one unprocessable message redelivered forever can stall a partition while the metrics say "busy"), and ordering assumptions (the moment two consumers run, "the order things happened" becomes a property you must design for, not one you get).

Backlogs deserve a policy, not a hope: what is the maximum age of work we will still perform? An email unsent for four hours may still be worth sending; a price update from four hours ago may be actively harmful. Queues without a time-to-live encode the answer "all work is eternal," which is rarely what the business believes. What the backlog's growth tells you is its own briefing.

What does the alternative cost?

The honest comparison is not queue versus nothing; it is queue versus synchronous call with a timeout, retry budget and circuit breaker, the pattern the Amazon Builders' Library documents better than we could. Synchronous keeps the failure in the caller's face, which is a feature: the user learns the truth now, not from a support ticket about an order that silently never processed. Queues move failure out of sight, and out of sight is where failure compounds.

Our rule of thumb, priced both ways: queue the work when the user does not need the answer to proceed, when bursts genuinely exceed capacity, or when retries must survive a consumer deploy. Keep it synchronous when the user is waiting and the truth matters more than the throughput. Either way, decide where unfinished work goes to be noticed. That decision, not the broker choice, is the architecture.