Capacity Is a Decision

If you run a capacity team, you usually know enough about the answer that you don’t ask the question out loud. Asking the people who maintain a complex service whether they have enough capacity is an invitation to be asked for more capacity, and at a large company you are careful about when you bring the topic up. If someone needs capacity, ideally you have already caught it in the data. A capacity team that has to wait for people to ask for more is a sign that something is wrong. That relationship — who promises, who relies on the promise, and who has to hear about the need early — is what this chapter is about.

Chapter 1 asked what computing costs: the bill, the five ways of reading it, and what the invoice leaves out. This chapter asks the other half: what the machines can actually promise, measured against what the business needs them to be able to do. Its subject is the reality of sizing a service and supporting the customers who rely on it. Measuring a system produces candidates: this configuration completed this much work under these conditions. Turning a candidate into capacity takes decisions the measurement cannot make. By the end of the chapter I want a manager to be able to state the promise, name its owner, and point at the evidence.

Most people think capacity is about having enough infrastructure to meet demand. That is the surface problem. Capacity is really about how an organization makes decisions under uncertainty, because it commits resources today on an imperfect prediction of what the business will need tomorrow. That is why capacity problems show up as cost problems, availability problems, planning problems, and organizational problems. The interesting question is not only “How much capacity do we need?” It is “How do we make good commitments when we can’t actually know what we’re going to need?”

The chapter uses one small constructed example — a web service built from workers we can count — to keep every claim checkable. The numbers are illustrative; the decisions about failure tolerance, timing, and ownership are ones a real service would have to make.

How to read this chapter

This chapter is about what turns a measured number into a promise an organization can keep: the decisions that surround capacity, and who owns each of them.

1. Specify the work before naming the size — a capacity statement is complete only when it names the work, the quality, and the conditions, including which failures the customer may rely on surviving.
2. Requirements can change faster than supply — what to do when a business-critical request arrives before the evidence, why the right answer for a new service is usually capacity rather than criticism, and why the commitment behind it should ramp with the evidence.
3. Headroom has a purpose — which limit headroom is measured against, why the same room cannot cover growth and a failure at once, and why “we don’t know yet” deserves a bounded investigation.
4. Elasticity: what it promises and what it costs — what elastic supply genuinely solves, why the ideal is easiest to deliver at small scale and hardest to guarantee at large scale, and the costs and limits that remain.
5. Autoscaling still needs someone to supply the capacity — the mechanism that requests capacity, why it cannot substitute for a supply plan, and what graceful degradation needs before anyone counts on it.
6. The burden of proof is on ownership — the strong default toward buying infrastructure services, where David Heinemeier Hansson’s case for owning hardware transfers and where it does not, a predictable spike that ownership turns into a year-round cost, and how to review an ownership case on its conditions.
7. Make the promise understandable — the closing test: can the person approving the launch explain what the customer receives and what must stay true?

Two lessons return throughout. First, the same machines support different promises depending on the operating condition the customer is entitled to rely on — the healthy service and the service after one failure are different answers to the same question — so the condition is part of the decision. Second, no measurement assigns an owner; a capacity number becomes real when a named person accepts the promise it supports.

Specify the work before naming the size

Capacity describes how much useful work a system can complete in a period under specified conditions, including its workload, quality requirements, dependencies, and operating state. Counting machines gets us part of the way there. To turn that inventory into something the business can promise, we have to understand what the machines can do together and what would change the answer.

The example this book reuses is a transaction-facing service built on 64 workers, each established at 250 completed requests per second under a representative test that also holds response time at the ninety-fifth percentile to no more than 200 milliseconds, with errors no greater than 0.1 percent of offered requests. Multiplying that rate by the number of workers assumes the service scales linearly, so I treat every configuration in this example as having passed the same test at its full size. These are synthetic results, not benchmarks for a product you can buy. The workers are divided into four groups of sixteen, each group running on separate hardware, power, and network so that the service keeps running, at reduced capacity, after losing any one group. I will call each of these a failure group. The label matters less than the design question behind it: what is allowed to fail together? In normal operation the service completes 64 × 250 = 16,000 requests per second; after losing one group, 48 × 250 = 12,000. Independence here is an assumption about that single-group event; it does not establish that all four groups would survive a shared control, network, or regional failure.

These four failure groups are an abstraction for the teaching model, and mapping them onto a real provider tests the arithmetic. Most Azure regions with availability zones have three, and a service may use only some of them.¹ Put four groups into three zones and one zone holds two. If the customer relies on the service surviving a zone loss, losing the zone with two groups takes 32 workers and leaves 32 × 250 = 8,000 requests per second, not 12,000. Fault domains, shared dependencies, and recovery behavior change the deduction the same way, so the failure group has to be drawn from the actual placement.

Historical demand suggests a next peak of 10,000 requests per second, and the full rollout would add 4,000. Set the resulting 14,000 against the healthy service’s 16,000 and the launch looks supportable; set it against the 12,000 left after a group loss and it is 2,000 short. The same machines support both answers, and the difference is the operating condition the customer is entitled to rely on. No measurement chooses that condition; a team has to decide it and say so.

Even our small web example has a dependency that can undo the arithmetic. Its rate is expressed in completed requests, but a request that reads a small cached object and one that scans a large history can put very different demands on the database. If the rollout changes the mix, we have to test the 250-request rate again. Reusing the old rate because the counter is still called requests per second would preserve the appearance of continuity after the underlying work had changed.

A batch customer might care about completing a body of work before a deadline; a streaming customer might need to carry new traffic while catching up on a backlog. An AI service has to finish a task at acceptable quality within a provider’s token and request limits or, if it runs its own models, within the GPU memory that the model and its cached context occupy. We will spend time on these differences because they determine whether additional resources are useful, and sometimes whether the resources we already have are useful in the way we assumed.

I would expect a capacity statement to explain the work included, how and when its limit was established, and what happened during the test. Were maintenance or failures present? Did the system reject work or push it into a queue while the completed-request metric looked healthy? What change would make the result inapplicable? A specialist needs enough detail to challenge the answer, and the person making the business commitment needs enough plain language to understand it. “The system scales” leaves both of them to fill in the missing answer themselves.

Requirements can change faster than supply

The Art of Capacity Planning opens its chapter on capacity goals with a line I agree with: “You wouldn’t begin mixing concrete before you know what you’re building.” Kejariwal and Allspaw put requirements for performance, availability, and reliability first, and because those requirements change as users’ expectations evolve, they treat the planning as continuous.² I would much prefer to work in that order. My objection is to a use of the advice they don’t propose: treating requirements as a gate a request must pass before anyone helps, when the request that arrived in the wrong order can be exactly the one the business now cares about most.

As the Introduction’s demonstration showed, an experiment can become business-critical before anyone has sized it for production. The capacity team is still looking for the original request while the business is discussing a launch date.

That doesn’t excuse careless engineering, but it does describe a situation our practice has to accommodate. For a new service, the right answer is usually capacity, not criticism. Punishing the team won’t bring supply forward, and making it harder to ask for help may mean that the next experiment reaches us even later.

I would begin by finding out which parts of the request have actually become commitments. The date may be fixed while the audience remains negotiable. A customer might need one workflow immediately and be willing to wait for another, or the demonstration might have established useful functionality without giving us any evidence about throughput. Each of those discoveries suggests a different next step, which is why asking for “the requirements” once and treating the answer as settled is rarely enough.

Supporting the request does not mean passing it to a provider unchanged. If a team thinks it is going to launch next year, ramp the commitment up over time and work out the ramp with the provider: you don’t want to give your provider an estimate that leaves 80 percent of the capacity unused. That puts the capacity team a little out in front of the engineering team and the business, and it is a risk you may have to take on. Sooner or later a team comes back and says, “Wait, we asked for 1 million cores by June.” They haven’t launched anything yet, it’s May, and until I see evidence that this is going to work, they are going to get 250,000 cores by June. If they demonstrate it, I can ask for more. What I won’t do is ask the provider to set aside 1 million cores for a team that then misses its deadline.

Our portfolio has a ramp of its own. A staged rollout would add 2,000 requests per second instead of 4,000. That brings the peak to 12,000, exactly what the service keeps after losing a group, with no margin at all. Eight compatible workers doing deferrable batch work could also move in for thirty days, after two days of preparation and testing. We learn those things from people who understand the customers and the platform, and together they give us an option that the original demand curve could not reveal. Chapter 4 works through what that option buys.

We still need to find out whether the batch delay is acceptable, whether the changed topology works, and whether later supply will be funded and ready. Finding a possible route through the shortage is useful progress, but the people affected have not yet agreed to take it. Volume II, Chapters 18 and 20 follow those obligations through their deadlines, including what happens when the borrowed workers are due back before the additional supply arrives.

Headroom has a purpose

Readiness complicates the picture further. A worker that takes two days to prepare may be useful for next week’s launch but irrelevant to a shortage beginning in the next minute. Resources without access to the necessary data will not restore a data service, however many of them the inventory shows. Placement, dependencies, and preparation time belong in the discussion before we label a resource available.

This is why I want a manager to be able to explain the purpose of apparently idle capacity and what would allow it to be released. Some of it will turn out to be unneeded, some deliberately available, and some insufficiently understood. The third category, where the honest answer is “we don’t know yet,” deserves the investigation Chapter 1 called for, with a boundary and a deadline.

Elasticity: what it promises and what it costs

Elasticity is the ability to add and release resources as demand changes. Whether the bill falls when we release them depends on the purchase arrangement. For workloads with genuine variation this is a real and valuable property. The alternative — holding permanent capacity sized for the busiest day of the year — strands supply on every quieter day. Elasticity converts that stranded supply into a rental that follows the demand curve, absorbs growth that would otherwise wait behind a purchasing cycle, and makes a temporary experiment affordable: start small, pay small, grow only if the work justifies it. Much of the case for buying infrastructure services, taken up shortly, rests on exactly these advantages.

The standard definition, from NIST, goes further: to the consumer, the capabilities “often appear to be unlimited and can be appropriated in any quantity at any time.”³ That is the ideal that shows up in a sales conversation, and at small scale it is real: a team whose busiest day needs three or four GPUs can rent them by the hour and release them at night, and the provider is content to have the capacity back. The picture changes as the numbers grow. I once asked a provider to support a workload that scaled from zero to 100 GPUs every day on a SKU that was often in short supply. To honor that pattern, the provider would have had to hold 100 GPUs ready somewhere — hardware the rest of the market was competing for at exactly the hours we were not using them. The provider came back with a different proposal: they could not reserve 100 GPUs for us when we were only going to use them half the time. A commitment that covers elastic scale at that size is effectively a commitment to pay around the clock, because somebody is holding the supply whether you are using it or not. Everyone who needs those GPUs needs them right now, and that competition is exactly what turns the dial back into a commitment.

The same conversation reaches small customers when the hardware is scarce, and the providers’ own terms show it. Azure bills an on-demand capacity reservation at the normal rate for its VM size from the moment it is created, whether or not anything runs on it; reserved-instance and savings-plan discounts can apply, but an idle reservation is still billed. Creating one fails if the region lacks the capacity, and as of October 2026 the ND-series and NCads H100 v5 GPU sizes cannot be reserved this way at all.⁴ AWS offers Capacity Blocks for machine learning: a fixed number of GPU instances for a fixed window of at least a day, starting up to eight weeks out, priced on supply and demand at the time of purchase, paid up front, and not cancellable.⁵ A workload that needs the GPUs for half of each day still buys the whole day. Neither arrangement is a dial. Elasticity at scale is an inventory promise somebody has to fund, and the bigger the swing, the more the arrangement converges on a reservation with a bill attached. Volume II, Chapter 14 takes up the demand side of this: when the variation in a workload is predictable, the swing itself becomes something you can plan and buy for.

For a particular workload, compare the cost over the period of use, not just the hourly rate. Suppose the around-the-clock commitment for those 100 GPUs comes at thirty percent below the on-demand rate, and the work keeps them busy twelve hours a day. Each hour actually used then costs 0.7 × 24 ÷ 12 = 1.4 times the on-demand rate. The commitment comes out ahead only if the GPUs are busy more than seventy percent of the time, the same break-even that Volume II, Chapter 20 reaches for a constructed take-or-pay agreement. Elasticity and a low total cost can go together; paying for unused committed capacity can reverse the apparent discount.

Elastic supply is still supply. A request to create capacity can fail on a stockout or in the busy interval when everyone else is scaling too, and a machine type listed in the catalog is not yet ready for our service. The six weeks our example estimates for sixteen additional workers covers delivery, preparation, and qualification against the service’s dependencies, with the new workers forming a fifth independent failure group. Elasticity widens the range of what can be rented quickly; it does not shorten the qualification path. “The platform will scale” is a supply claim, and supply claims need the same evidence as purchases.

Elasticity can also quietly remove the sizing decision from view. If a team enables automatic expansion without agreeing limits, its scaling policy can authorize consumption beyond what the budget owner expected. The resulting bill may be a surprise even though the mechanism did exactly what it was configured to do. Elastic supply still needs an owner — the promise, its limit, and the person who explains both.

Autoscaling still needs someone to supply the capacity

For our service, autoscaling can help use the sixteen additional workers once they are qualified and available, but the launch needs a plan for the six weeks before then, including the possibility that readiness slips. I would be uncomfortable approving the launch on the strength of an autoscaling policy if nobody could explain that interval. Chapter 6 follows the control loop itself, keeping desired, allocated, and usable capacity in view.

The suggestion to degrade gracefully needs the same scrutiny. It may be a good option, but I want to know which operation can be delayed, whether the implementation preserves correctness while restricting it, and who has agreed that the reduced service is acceptable. Calling the customer a bank, a government agency, or a retailer doesn’t answer those questions. Within any of them, some work may tolerate delay while another transaction must remain correct under conditions that leave very little room to compromise.

The business owner and operating specialists need to define the reduced service before an incident forces the discussion. If they cannot find an acceptable mode, we have learned something important about the reserve we need to preserve. The cheaper plan doesn’t become feasible because its spreadsheet assumes a concession the customer cannot make.

The burden of proof is on ownership

My default is that most organizations should buy infrastructure services rather than hardware. There are exceptions, and I want to understand them, but purchasing private infrastructure should follow an informed decision about the operating responsibility we are taking on. Being able to afford the equipment is a fairly small part of that decision.

David Heinemeier Hansson has argued the other side in public, in detail, and he has earned a careful hearing. He created Ruby on Rails, which began at 37signals in 2003 as the framework for Basecamp and has been sustained since by a broad community.⁷ I respect that work, and I take his argument for owning infrastructure seriously. I have followed it since I interviewed him about Rails in Chicago years ago, an interview that ended halfway through with the two of us sprinting away after a parks official called the police about my unpermitted filming.⁸ In the years since, I have never seen him argue from fiction; he argues from conviction, backed by evidence, and he does not back down. He has also been unusually open about the decision: he published 37signals’ $3.2 million cloud budget for 2022 and the $600,000 server order that carried the exit, and he released Kamal, the deployment tool he wrote for the move, as open source.⁹

Read the details before disagreeing with him. He describes 37signals as having “a business model that’s incredibly compatible with owning hardware and writing it off over many years,” “growth trajectories that are mostly predictable,” and expert staff to run its own machines.¹⁰ His FAQ adds that the same team operates the applications after the move, that the servers sit in professional data centers where a service provider racks them, and that each of the two sites can carry the full load.¹¹ This isn’t an account of a few developers casually deciding to build a datacenter, and on those conditions the decision can be right for 37signals. My disagreement is with the broader recommendation: that most SaaS businesses of 37signals’ size and above should own their infrastructure rather than rent it.¹² What I want to challenge is the ease with which another organization can adopt that conclusion without the conditions that support it.

Predictability is the condition I would test first, and his own example shows why. When 37signals launched HEY, 300,000 people signed up in three weeks against a forecast of 30,000 in six months, and he credits the cloud with carrying it.¹³ He doesn’t ignore spikes. He recommends buying powerful machines “a fair step ahead of your growth curve,” cites “buy the baseline, rent the spike” for businesses that regularly see large swings, and expects an unplanned expansion of owned hardware to take “a week or so.”¹⁴ That is coherent for a business whose surprises are rare and whose servers are commodity machines. The question for another organization is how often it produces a HEY launch, and what it would have to buy in a hurry. The GPU workload from the elasticity section is the hard case: expensive to overprovision, unlikely to be quick to buy when the same SKU is scarce to rent, and, as that section priced it, expensive to rent as a spike.

Some spikes are perfectly predictable and still expensive to own. One example from my own experience involved a major system that cost tens of millions of dollars a year to run on public cloud. Once a year it had to run a business-continuity test that doubled its size, to demonstrate that it could switch over immediately if it ever needed to, and the team had worked out the timing with the provider so that it could get that capacity for two or three weeks. Then the team was told it was moving to private cloud, and it asked the obvious question: in private cloud, for two weeks a year, can we have double capacity? The answer was no. Private capacity is not elastic capacity that someone else pays for; all of it is yours, whether it is used or not. If the test is a requirement, the private estimate has to carry twice the system’s capacity all year so that it is there for those two weeks. That is the kind of cost that surfaces late in an ownership comparison. “Buy the baseline, rent the spike” is sound advice when there is still somewhere to rent the spike.

Consider the experienced team. It is a valuable asset, but retaining the people you have today and sustaining that capability are related problems with different time horizons. People leave, take time off, and encounter failures outside their previous experience. Meanwhile, the platform may be asked to absorb another business, support unfamiliar database engines, satisfy different regional requirements, or accommodate an AI program whose demands are still changing. The workload that made the original purchase attractive may not describe what the platform is expected to support two planning cycles later.

Colocation and managed services can supply parts of the operating capability, so I am not suggesting that every organization must reproduce every service in a hyperscaler’s catalog. Define the platform you actually need, then follow the responsibilities across its boundaries. When an incident crosses from the application into storage, networking, or the facility, who can diagnose it, who can act, and where does one supplier’s obligation end? Those interfaces are part of what you are buying or building.

The less exciting work belongs in the comparison too: replenishing specialist knowledge, replacing equipment, testing restores, maintaining security responsibilities, qualifying new hardware, arranging escalation, and carrying old and new capacity during refreshes. Chapter 13 works through what a first ownership comparison usually leaves out, the staff above all, and asks for each refresh overlap in its cash schedule. Before the prices can tell us much, we need a credible account of who will keep doing the work after the migration announcement has stopped being interesting.

Public cloud doesn’t relieve us of application design, the operating responsibilities our chosen services retain, or demonstrating that recovery works. A provider is not an automatic business-recovery policy. My preference is for buying specialized capability where that arrangement is more credible than maintaining it ourselves, and asking for evidence before bringing those responsibilities inside.

A fair analysis must be capable of recommending ownership in an unusual, well-supported case, and the elasticity argument shows where to look: a large, steady footprint that is already committed around the clock has given up much of what renting buys. It must also be capable of rejecting an attractive equipment price because the proposal has left out the organization needed to use the equipment. I don’t think those positions are inconsistent. They are why my default remains strong even for an enterprise large enough to write the check.

Make the promise understandable

That explanation lets the organization discuss the choices without mistaking a possible engineering configuration for an approved business plan. We still need someone entitled to accept the batch delay, choose which customers enter the first stage, decide how to cover the interval between the borrowed workers’ return and the new group’s estimated readiness, and authorize any change to the reliability promise. The next step is to bring those people into the decision while there is still time for them to change it. That is also what a good answer to “do we have enough capacity” sounds like — specific about the present, explicit about what would change it, and honest about who decides.

Notes and sources

1. Microsoft Learn, “What are Azure Availability Zones?”, checked October 3, 2026, and “List of Azure regions”, checked October 4, 2026. The region list shows three zones for every zone-enabled region except East US 2, which has four. It distinguishes the zones in a region, the zones a service uses, and the number of instances or replicas. The book’s failure groups are synthetic.↩︎

2. Arun Kejariwal and John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud, 2nd ed. (O’Reilly, 2017), chapter 2, “Setting Goals for Capacity”, checked October 3, 2026. Places the requirements for performance, availability, and reliability before capacity planning and calls the planning “not a one-time process, but a continuous one.” The objection to treating requirements as a gate is the author’s, not the book’s.↩︎

3. Peter Mell and Timothy Grance, The NIST Definition of Cloud Computing, NIST SP 800-145, September 2011. Defines rapid elasticity as provisioning and releasing capabilities “commensurate with demand”; source of the quoted phrase. A characteristic, not a tariff or a supply guarantee; the economic comparison is the author’s.↩︎

4. Microsoft Learn, “On-demand capacity reservation in Azure”, checked October 3, 2026. A reservation is priced at its VM size’s rate and billed whether or not it is used; reserved-instance and savings-plan discounts can apply to it. Creation fails without available capacity, and ND-series and NCads H100 v5-series sizes are listed as unsupported. The 100-GPU provider conversation in the preceding paragraph is the author’s recollection, paraphrased, with the provider unnamed.↩︎

5. Amazon Web Services, “Reserve GPU instances for ML workloads — Amazon EC2 Capacity Blocks for ML” and the EC2 user guide’s Capacity Blocks for ML pages, checked October 3, 2026. A block holds up to 64 instances for one day to 182 days, starting up to eight weeks out; its price depends on supply and demand at purchase, is charged up front, and gets no Savings Plans or Reserved Instance discount; cancellations aren’t allowed. Vendor documentation, not an independent assessment of availability.↩︎

6. Microsoft Learn, “Check vCPU quotas”, checked October 3, 2026. Defines quota as a subscription’s permission to deploy and capacity as the compute available in a region or zone, says a deployment with sufficient quota can still fail for lack of capacity, and suggests a different size, zone, or region, or an on-demand capacity reservation.↩︎

7. Rails Foundation, “37signals”, accessed October 3, 2026. States that Rails was started in 2003 to build Basecamp, identifies DHH as its creator, and lists Kamal among 37signals’ open-source projects. The assessment of the contribution is the author’s.↩︎

8. Tim O’Brien, “Leaving the Cloud Isn’t for Everyone: When DHH’s Math Makes Sense — and When It Doesn’t”, Medium, October 31, 2025. The interview recollection and the characterization of his arguments are the author’s own.↩︎

9. David Heinemeier Hansson, “The Big Cloud Exit FAQ”, December 19, 2023. Source of the budget and server-order figures, Kamal’s origin, the unchanged team, the data-center arrangements, the two full-load sites, and his advice on spikes and expansion. His reported figures and arrangements, not audited ones; the transferability judgment is the author’s.↩︎

10. David Heinemeier Hansson, “Why we’re leaving the cloud”, October 19, 2022. Source of the quoted conditions, the HEY launch figures, and his exceptions for simple, low-traffic applications and highly irregular load. His account, not an independent audit of the economics.↩︎

11. David Heinemeier Hansson, “The Big Cloud Exit FAQ”, December 19, 2023. Source of the budget and server-order figures, Kamal’s origin, the unchanged team, the data-center arrangements, the two full-load sites, and his advice on spikes and expansion. His reported figures and arrangements, not audited ones; the transferability judgment is the author’s.↩︎

12. David Heinemeier Hansson, “Five values guiding our cloud exit”, February 22, 2023. States the broader recommendation: “Most SaaS business of our size and above should be owning their infrastructure rather than renting it.” The same post says the cloud “has its place” and credits it with the HEY launch.↩︎

13. David Heinemeier Hansson, “Why we’re leaving the cloud”, October 19, 2022. Source of the quoted conditions, the HEY launch figures, and his exceptions for simple, low-traffic applications and highly irregular load. His account, not an independent audit of the economics.↩︎

14. David Heinemeier Hansson, “The Big Cloud Exit FAQ”, December 19, 2023. Source of the budget and server-order figures, Kamal’s origin, the unchanged team, the data-center arrangements, the two full-load sites, and his advice on spikes and expansion. His reported figures and arrangements, not audited ones; the transferability judgment is the author’s.↩︎