Background job queues vs synchronous requests

What it means

Synchronous handling ties the request’s lifetime to finishing the work. A background queue separates the handoff from later execution by workers, so the application needs distinct meanings for accepted, completed and failed.

That separation can change the caller’s experience without changing how much processing is available. A quick acceptance response is not evidence that the business work finished or that the system can sustain the incoming rate. Nor does choosing a queue by itself establish durable storage: the acceptance guarantee depends on the actual queue and application contract.

Try it

Simulation: inspect the baseline, then change Worker capacity (jobs/s) from 15 to 25. Read how the result changes, and select Compare with baseline to view both outcomes. Editing an input clears the previous comparison. Reset returns to the initial inputs. The example remains readable without JavaScript; the controls require JavaScript. No external action is performed.

300 queued job-equivalents. Incoming 1200, service budget 900; excess demand is 300. 20.0 s to drain after arrivals stop. The backlog grows because demand exceeds capacity by 5 jobs/s for 60 s, not because the work is labeled queued.

Keep Handling model = queued jobs, Incoming work (jobs/s) = 20 and Observed interval (s) = 60. Change only Worker capacity (jobs/s) to 25.

Reset restores Handling model to queued jobs, Incoming work to 20 jobs/s, Worker capacity to 15 jobs/s and Observed interval to 60 s. It clears input errors and the baseline comparison. There is no running clock or stored event history to reset. Your independently opened or closed FAQ answers and About this model panel stay as you chose them.

How it works

The causal chain is arrival rate → work arriving during the interval → demand left after the available service budget. Starting with no backlog, the model calculates:

backlog = max(0, (incoming jobs/s − worker jobs/s) × interval s)

When arrivals exceed capacity, each second adds the positive rate difference to unserved work. Queueing lets that work wait separately from the initiating request, but workers still have to perform it. A temporary excess can be absorbed only if later service has room to catch up; sustained excess keeps accumulating under these assumptions.

Switching Handling model from queued jobs to waiting synchronous callers leaves the arithmetic unchanged and labels the result as waiting work-equivalents. This isolates the capacity imbalance. It does not calculate a number of HTTP connections or imply that callers can wait indefinitely; timeouts and admission limits are outside the model.

After arrivals stop, positive capacity drains the calculated backlog in backlog ÷ worker capacity seconds. This is conditional on arrivals stopping, not an estimate while the same demand continues. If capacity is zero and backlog is positive, the model reports no drain while capacity is zero. If both arrivals and capacity are zero, there is no backlog—not an infinite drain time.

Worked example

This is a synthetic example, not a production observation.

Over 60 s, 20 × 60 gives 1200 incoming job-equivalents. Workers have a service budget of 15 × 60 = 900. With no initial backlog and constant excess demand, the remaining 300 accumulate as queued job-equivalents.

The intermediate fact is the 5 jobs/s shortfall: changing only the waiting location cannot remove it. If arrivals then stop and workers continue at 15 jobs/s, the accumulated 300 take 300 ÷ 15 = 20.0 s to drain. If arrivals instead continue at 20 jobs/s, that drain estimate does not apply; the backlog continues growing. Acknowledging durable enqueue is not completion of the business work.

What changes when the condition changes

Change Worker capacity (jobs/s) from 15 to 25. Keep Handling model = queued jobs, Incoming work (jobs/s) = 20 and Observed interval (s) = 60.

0 queued job-equivalents. Incoming 1200, service budget 1500; excess demand is 0. 0.0 s to drain after arrivals stop.

Capacity now exceeds incoming demand, so no excess accumulates under the constant-rate assumptions. The service budget of 1500 is potential capacity, not 1500 completed jobs: only 1200 arrive. The spare budget is unused. The displayed 0.0 s means there is no accumulated backlog to drain; it does not mean each job takes zero time or that a real request has zero latency.

In practice

Compare the two approaches against the result your caller actually needs:

For example, generating a report that a user can collect later is a plausible queue candidate. If a response must contain a finished calculation before the caller can proceed, synchronous handling may be the better fit. Duration alone does not decide the architecture; the required response contract matters.

Before planning a handoff, use read-only documentation, configuration and existing metrics for an application you are authorized to inspect. Limit the assessment to the operation being considered: identify what counts as acceptance, how a job is identified, where completion or failure becomes visible, the observed arrival and completion rates, and the queue’s delivery guarantees. The expected outcome is evidence that the operation can finish later without losing trustworthy outcome tracking—not merely a faster initial response.

STOP short of deploying the handoff if acceptance could be mistaken for completion, duplicate processing could repeat an unsafe business effect, or capacity and backlog limits are unknown. Plan bounded admission rather than allowing unbounded work to accumulate. This page is an architecture comparison, not a broker migration or deployment procedure; it does not authorize configuration changes or supply a deployment rollback plan.

Limits and unknowns

The model starts empty and assumes constant rates throughout the selected interval. It does not represent bursts, existing backlog, retries, priorities, individual job durations, broker persistence or request timeouts. Its service budget is capacity available over the interval, not an observed completion count. A zero modeled backlog therefore does not establish acceptable real-world response times.

Incoming work and Worker capacity each accept values from 0 to 1000 jobs/s; Observed interval accepts 1 to 3600 s. An empty, nonnumeric or out-of-range numeric input is invalid. The old result is removed, and no calculated outcome applies until you correct the input or use Reset.

Valid inputs produce a local arithmetic result, not a diagnosis of a deployment. Actual durability, delivery behavior, sustainable capacity and user-visible completion remain unknown without evidence from your application and queue. The Simulation accesses no real machine, account, request or service.

What to carry forward

Choose a queue when acceptance can be separated from completion and your application can make that distinction trustworthy. Choose synchronous handling when the caller needs the completed result in the response and the operation fits the request’s constraints. In either case, compare incoming demand with sustainable service capacity: moving the waiting does not remove the capacity requirement.