A platform lead argues that because every service now scales automatically with load, the company can drop its capacity planning process entirely. You are accountable for both reliability and infrastructure spend — how do you answer?

## What the loop actually does Automatic scaling is a feedback controller. It observes a signal, compares it to a target, and adjusts a count within a configured range, drawing from a pool of capacity that someone already arranged to exist. Every part of that sentence has a limit in it: the signal lags, the range has a maximum, and the pool is finite. Capacity planning is a different activity. It decides how large the pool should be, where it should physically live, what it should be bought under, and which of its inputs need to be ordered weeks ahead. Elasticity makes planning less granular. It does not make it unnecessary. ## Ceilings the controller cannot raise - **Account and region quota.** Limits on cores per instance family, addresses, load-balancer objects, managed-service instances, function concurrency. A scaling maximum set above the quota is fiction, and the failure surfaces as a quota error during a surge. - **Physical capacity for a shape.** Quota is permission; it is not a reservation. A scarce instance type in a specific zone can be unobtainable at the exact moment demand arrives. - **Stateful tiers.** Databases, shard counts, log partitions and cache tiers do not scale on the same timescale as stateless replicas, and frequently not automatically at all. In most architectures they are the true capacity limit, so scaling the stateless tier into them makes the incident arrive faster. - **Third-party and internal platform limits.** Payment processors, messaging providers, identity services and shared internal platforms enforce their own rates. Scaling past them converts your capacity into their throttling. - **Licences and contracts.** Per-core or per-node pricing tiers move on business calendars. ## Reaction time versus arrival shape A control loop needs a metric window, then a provisioning call, then boot, registration and warm-up. That is minutes for most stacks. Demand from a push notification, a doors-open sale or an upstream failover arrives in seconds. The mitigation is not a faster loop, it is a **floor derived from a forecast**: minimum fleet sizes raised ahead of known events, warm pools, pre-warmed serverless concurrency, primed caches and established connection pools. Elasticity then handles the surprise on top of a fleet that was already correct for the plan. ## The money argument is the stronger one Even granting perfect elasticity, the purchasing decision is unavoidable. Discounted long-term commitments are priced against a term — you are betting that a floor of demand exists for one or three years. That bet requires a forecast to make at all: - Commit too little and you pay on-demand rates on a steady baseline that was never going away. - Commit too much and a demand miss becomes sunk cost you cannot scale away from. The usual shape is to commit to the confident floor, run the volatile middle on-demand, and put interruptible work on preemptible or spot capacity — but every one of those boundaries is a number that comes out of a forecast. "We autoscale" is not an input to that decision. ## Somebody must own the aggregate Each team can size its own service correctly and the company can still fail, because the sum of every team's configured maximum has to physically exist in the region on the worst day. No single team can see that total. That is the irreducible central function: collect per-service forecasts, convert them to resources, aggregate by region and by instance family, compare against quota and reservations, and track the lead-time items. It is also where launches get caught — the campaign that four teams are unknowingly serving at once. ## What I would actually propose Replace the heavyweight process with a light one that keeps only the parts elasticity cannot do: 1. A short forecast per significant service, refreshed quarterly, expressed in resource units. 2. Aggregation per region against quota and reservations, owned by the platform or SRE group. 3. A calendar of demand events — launches, campaigns, seasonal peaks — with lead-time items tracked to a date. 4. A purchasing position revisited each cycle: what fraction of the fleet is committed, on-demand, or preemptible. 5. Explicit ownership of the stateful tiers' capacity, because that is where the real ceiling usually is. ## How you know the process was dropped too early The signature is distinctive: capacity incidents that show up as quota errors, unavailable instance types or exhausted database connections rather than as high utilization; scaling maximums nobody can justify; and the platform team learning about a launch from the traffic graph. If those are appearing, the planning function was not eliminated — it was just left unowned.