This original fictional export service receives 12 jobs per second for five minutes, then 2 jobs per second afterward. Its workers complete a combined 8 jobs per second. Start with an empty queue and a simplified constant-rate model with no failures or variation.
Calculate the burst before proposing a fix
During the burst, the arrival rate exceeds the completion rate by 4 jobs per second. Across 300 seconds, the queue accumulates 1,200 jobs. Once arrivals fall to 2 per second, spare capacity is 6 jobs per second, so clearing that backlog takes another 200 seconds under the model.
| Period | Arrivals per second | Completions per second | Backlog change |
|---|---|---|---|
| Five-minute burst | 12 | 8 | Grows by 4 jobs per second |
| After the burst | 2 | 8 | Shrinks by 6 jobs per second until empty |
| Hypothetical sustained peak | 12 | 8 | Continues growing without a finite drain time |
The 200-second figure is time to drain the accumulated queue while new work continues arriving. It is not the wait of every job. Under a further FIFO assumption, a job arriving near the end of the burst has approximately 1,200 queued jobs ahead of it; at 8 completions per second, its queue wait is about 150 seconds, plus its own service time. Scheduling and varying job sizes can change that estimate.
Microsoft's queue-based load-leveling guidance, checked October 24, 2026, describes buffering and its operational considerations. The numbers here are authored exercise inputs, not measured service performance.
Ask for a decision tied to an objective
Review a queued export design; do not provision services or write code.
Arrival pattern: 12 jobs/second for 300 seconds, then 2/second.
Combined completion capacity: 8 jobs/second, initially empty queue.
First use constant rates and no failures; label this simplified model.
Proposed user objective: [ENTER MAXIMUM WAIT OR COMPLETION TARGET]
Job-size distribution, scheduling, retry and worker limits: [PASTE]
Calculate backlog at burst end, drain time with continuing arrivals,
and the distinction between queue wait and time to empty the queue.
Compare burst buffering, more processing capacity and admission control.
State assumptions and measurements each option requires. Do not invent
cloud quotas, prices, throughput benchmarks or an achieved service level.
Identify what fails if peak arrivals continue indefinitely.
OpenAI's prompting documentation supports supplying context and boundaries. A design response should expose its arithmetic and unknowns so a reviewer can challenge them.
Measure the constraint before adding workers
Real export jobs can have different durations and contend for the same database or external service. Measure completion rates, queue age and error behavior under a representative workload. Adding workers may move the bottleneck or overload a dependency; an assumed linear speedup is not a benchmark.
If the acceptable wait is shorter than the burst can support, review capacity, job scheduling and limits on accepted work. Decide what users see when admission is refused or delayed. For duplicate delivery and uncertain writes, use the separate workflow retry guide. Keep the capacity decision and recovery decision explicit, then validate both in an authorized test environment before promising a completion time.