Queue Autoscaling Playground

Assumptions and limits

• A finite, deterministic trace runs on a one-second clock. Completions happen before arrivals, scaling, and dispatch. At the cutoff only completions are processed; new work is not started.
• Each worker runs one non-preemptible job at a time. A job occupies one downstream slot for its entire service duration. This is a concurrency bottleneck, not a universal requests-per-second model.
• Admission is tail-drop at a global unfinished-job limit, including running work. Rejection is explicit and never retried automatically; tenant scheduling does not make admission tenant-fair.
• Round robin rotates by JOB, not CPU time. Priority is strict but non-preemptive. The per-tenant cap restricts simultaneous running jobs; idle capacity can remain when every queued tenant is capped.
• Completion percentiles describe only jobs completed before cutoff. Pending and rejected counts, and oldest unstarted wait, must be read alongside them; no service before cutoff is not proof of permanent starvation.
• Deadlines use acceptance/arrival time and include waiting plus service. Only accepted jobs whose deadlines have matured by cutoff enter the deadline count; rejected work remains a separate outcome.
• Worker-seconds count booting, idle, busy, and gracefully draining workers in [0, cutoff). No price, real scheduler behavior, retry storm, network latency, or production SLO is inferred.
• Baseline arrivals are spaced evenly across the observation interval; an extra burst arrives at one explicit second. Every job has the same service time and uses FIFO.
• The minimum pool is already warm at second zero. Newly launched workers wait for startup; starting workers count toward controller targets and the maximum live pool.
• The depth controller targets ceil((waiting + running) / jobs-per-worker). The age controller adds one worker per poll at or above the age target and removes one below half the target; nonempty work wakes a zero-sized pool.
• Downscaling is held for the cooldown after any applied target change. It stops idle/starting workers first and retires busy workers after completion; a new scale-up can cancel retirement.
• These are explicitly defined teaching controllers, not replicas of Kubernetes HPA, KEDA, SQS scaling, or a provider's billing rules. No retries, job preemption, worker failures, or stochastic arrivals are included.