What does an application give up by adopting queue-based load leveling for a request that used to be handled synchronously? Name and explain at least two concrete costs.

## Cost one, the request/response contract goes away The first and most structural cost is giving up the request/response contract. In a synchronous call, the caller sends a request and the same call returns the final answer; the caller's code can be a straight-line sequence of "do the work, get the result, use it." Once a queue sits in between, the caller can only get an acknowledgment that the work was accepted, not the result, because the result won't exist until some worker, running independently and on its own schedule, finishes processing later. Every caller of that endpoint now has to be rewritten around an **asynchronous completion model**: - polling a status endpoint until the job is done - registering a webhook the worker calls back on completion - or subscribing to a push channel like a websocket or a mobile push notification This is not a small change; it ripples into client UX (spinners, "we'll email you" messaging), API design (job IDs, status codes), and testing (races, timeouts on the polling side). ## Cost two, latency becomes variable The second cost is latency, and specifically variable latency that depends on system load rather than on the work itself. | Call | Latency | |---|---| | **A direct call's** | roughly constant: however long the service takes to do the work, plus network overhead | | **A queued call's end-to-end** | that same processing time plus however long the message sits waiting behind whatever backlog is ahead of it, and that wait time can range from near-zero when the queue is empty to minutes when a burst is being drained | This variability is precisely the trade the pattern makes: it exchanges a hard ceiling on the system's stability for a soft, unpredictable ceiling on how long an individual request's true completion takes. Any workload with a hard interactive-latency requirement, a checkout confirmation the user is staring at, an API with a contractual sub-second SLA, is a poor fit unless that variability is explicitly acceptable or bounded some other way. ## Cost three, new infrastructure and new failure modes Third, the pattern adds genuinely new infrastructure and new failure modes that a direct call never had to consider. The queue itself is now a stateful, durable system that must be provisioned, monitored, and kept healthy: **queue depth**, **oldest-message age**, and **dead-letter-queue counts** become metrics someone has to watch and alert on. - **Poison messages**, ones that repeatedly fail processing due to a bug or bad data, can jam a naive worker implementation in an infinite retry loop unless a dead-letter queue and a retry-limit policy are designed in from the start. - **If the broker itself has an outage or is under-provisioned**, both producers and consumers are affected, which is a new single point of failure that didn't exist in a purely synchronous chain (though the synchronous chain had its own single point of failure in the downstream service, so this is a shift rather than a pure addition). ## Cost four, at-least-once delivery forces idempotency Fourth, most practical message queues (`SQS` standard queues, `RabbitMQ` with typical acknowledgment settings, `Kafka` consumers that commit offsets after processing) provide **at-least-once** delivery, not **exactly-once**, meaning a message can be redelivered and processed more than once, for instance if a worker crashes after finishing work but before acknowledging the message. Consumers therefore need to be written **idempotently**, so that processing the same message twice produces the same end state as processing it once (for example, using an idempotency key to detect and skip a duplicate charge). Retrofitting idempotency onto business logic that was written assuming a call happens exactly once is real engineering work, and getting it wrong silently produces duplicate side effects like double-charging a customer or double-sending an email. ## Why the costs are the point All of these costs are the deliberate price paid for the pattern's benefit, protecting the system from being overwhelmed by bursty load and letting producer and consumer scale independently, so the right framing in an interview or a design review is not "is this cost avoidable" but "is this workload one where these costs are acceptable given how bursty the traffic is and how strict the caller's latency and consistency requirements are." A payment-authorization call a user is waiting on synchronously is usually a bad fit; a video-transcoding job or a nightly report generation is usually a good one.