In a rolling update you can configure how many instances may run above the desired count (surge) and how many of the desired count may be missing at once (unavailable). What do these two budgets trade off, and how does each extreme setting fail?

## The two budgets define a corridor A rolling update replaces a fleet piece by piece. The two budgets tell the controller how far it may stray from the desired count in each direction while it does so: ``` desired = 20, surge = 5, unavailable = 5 floor: 20 - 5 = 15 instances always available ceiling: 20 + 5 = 25 instances may exist at once ``` The floor is a promise to your users: capacity never drops below it. The ceiling is a bill: those extra instances consume real CPU, memory, IP addresses, database connections and licence seats for the duration of the rollout. Every rolling update is a negotiation between the two, and the negotiation is settled with spare capacity — that is the resource the whole strategy runs on. ## Surge set to zero With no surge allowance the controller cannot create before it destroys. It must take instances out of service first, then replace them. The fleet therefore runs below the desired count for the entire rollout — best case by one instance, typically by whatever the unavailable budget allows. For a service running at 30% utilisation, nobody notices. For a service running at 75% utilisation with a 25% unavailable budget, you have just removed the headroom the service was using to absorb its own variance. Latency climbs, queues build, timeouts start firing upstream, and — the part that catches people — autoscaling may react to the load spike by trying to add instances in the middle of a rollout, which the controller is simultaneously trying to converge. The release looks like it caused a performance regression when what it actually caused was a capacity shortfall. ## Unavailable set to zero This is the safe-looking setting, and it is the one that stalls. Promising that no instance may be missing forces the controller to start a replacement and wait for it to become healthy before it removes anything. That requires the platform to find room for the surge instances right now. If the cluster is full, the node pool is at its scaling ceiling, the quota is exhausted, an IP range is exhausted, or a pod anti-affinity rule leaves nowhere to place them, the new instances never start. The rollout does not fail loudly — it sits there, half-converged or not started at all, with the old version still serving. Teams discover this hours later when they wonder why the fix is not live. The same setting also multiplies downstream pressure. Twenty-five instances instead of twenty means 25% more database connections, more open file handles, more licence consumption, and more concurrent calls to a rate-limited partner API — briefly, but exactly while you are also introducing new code. ## Both budgets small Surge of one and unavailable of zero is the most conservative correct configuration and it is often the wrong one. It replaces instances one at a time, so a fleet of sixty takes sixty sequential health-check cycles. Two consequences matter more than the wall-clock time: - **The mixed-version window is long.** Old and new code serve side by side for the entire rollout, which means every request must be safe under both, and any schema or contract change must be backward compatible for far longer than anyone pictured. - **Your rollback is slow too.** Rolling back is another rolling update, subject to the same budgets. If it takes forty minutes to roll forward, it takes about forty minutes to roll back — which is the number that actually matters during an incident. ## Both budgets large A surge equal to the desired count is effectively a blue-green switch performed by the rolling controller: a whole second fleet appears, then the old one drains. A large unavailable budget is the opposite — it replaces most of the fleet at once, which is fast and cheap and removes the blast-radius protection that made you choose rolling in the first place. If half the fleet can be new before anyone looks at a metric, a rolling update has stopped being a progressive rollout. ## The budgets are only as real as the readiness signal All of this arithmetic assumes the controller can tell when a new instance is genuinely serving. If the health signal is a process that has started or a TCP port that is open, instances are counted as available while they are still loading configuration, filling connection pools, or compiling hot paths. The floor you configured is then fictional: you promised fifteen serving instances and delivered fifteen instances of which several return errors. Getting the readiness signal to mean *ready to take a real request* is what makes the budget mean anything, and it is the single most common reason a correctly configured rolling update still drops traffic. ## Choosing Start from the service's utilisation and its spare capacity. If there is headroom, prefer surge over unavailable: pay resources, keep capacity. If there is no headroom, either accept a small unavailable budget with a plan for the load, or pre-scale the fleet before the rollout so the surge has somewhere to go. Then size both so that the total rollout time is a rollback time you are willing to live with.