A developer platform's CI system faces a burst of builds after a major release. How should queues, workers, caching and prioritisation prevent collapse?

The controls

1. Priority classes, not first-in-first-out. Not all builds are equal: a release build, a build blocking a merge, and a scheduled nightly have different urgency. FIFO is not a scheduling policy; it is the absence of one, and under burst it means the most urgent work queues behind the least.

2. Per-repository and per-organisation concurrency limits, so one repository's burst cannot consume the fleet. This is bulkheading, and without it a single large monorepo starves everyone else.

3. Aggressive caching, layered. Dependency caches, compiled artefacts, container layers and test fixtures. For a burst of similar builds, cache hit rate is the largest determinant of throughput — and the highest-value detail is layer ordering stable-to-volatile, since getting it backwards means every commit re-downloads all dependencies.

4. Warm pools. Pre-provisioned and initialised runners, added in seconds rather than minutes. Autoscaling responds in minutes; a merge burst arrives in seconds.

5. Backpressure with honest feedback. When the queue exceeds a threshold, tell users the expected wait rather than accepting silently. A visible queue is manageable; an invisible one produces retries and duplicate builds.

6. Cancel superseded builds. When three commits land quickly on the same branch, only the latest usually matters. This is often the single largest capacity recovery available and costs nothing.

7. Test selection. Run only what the change could affect, with a full run on merge. For a large codebase this converts the dominant cost into a fraction of itself.

The security constraint that shapes the design

Builds run semi-trusted code, so trust separation is structural: contributions from outside run in a restricted context with no deployment credentials, and the pipeline definition itself must come from the trusted branch — otherwise a contributor who edits the workflow bypasses every other control.

The metric that matters

Time from push to feedback, at the percentile developers actually experience. A mean of four minutes with a p95 of forty means most developers have context-switched, and context-switching is the real cost of a slow pipeline — far larger than the compute.