Capacity planning and cost
What the design costs per month, and which line of the bill you would attack first.
What problem does capacity planning solve?
Every design decision is also a spending decision, and interviewers at some companies ask about it directly. "How much does this cost to run?" is a question many otherwise strong candidates struggle to start on.
You are not expected to quote a price list. You are expected to know the shape: which component dominates, what drives it, and what you would change if the answer came back too high.
What capacity planning costs you
Every concept in here states a cost. A technique with no price is a technique you have not understood yet — and naming the cost out loud is most of what separates a senior answer from a junior one.
When to reach for capacity planning, and when not to
Use it when
- Whenever the numbers stage produces a big storage or bandwidth figure. Say what it costs.
- When choosing between two designs that both work. Cost is a legitimate tiebreaker and a strong one.
- Any question about video, images, logs or analytics, where storage and egress dominate.
Do not, when
- Do not quote precise prices you are not sure of. Orders of magnitude and ratios are what matter.
- Do not optimise cost before the design works. A cheaper broken system is still broken.
How capacity planning actually works
Storing a terabyte is cheap. Serving it repeatedly is not, which is why a CDN is a cost decision at least as much as a latency one. Cross-region transfer is a separate line that is easy to forget.
The method is the same back-of-envelope you already do, with one more step. You already estimated requests per second, storage per year and bandwidth. Now attach a rough price to each and see which one dominates. It is rarely spread evenly. Often one line dominates the bill, and that line is where optimisation pays.
The usual suspects, in the order they usually bite. Bandwidth out to users, for anything media-heavy, which is why a CDN pays for itself. Storage, when you keep raw data forever because nobody decided a retention policy. Compute, which people assume is the big one and often is not. Managed services, which are excellent value until a per-request price meets a high-volume path. And the two that often go uncounted: cross-region transfer, and observability, since logs and metrics can cost more than the service that emits them.
Capacity planning is the same arithmetic pointed at machines instead of money. Take peak requests per second, divide by what one instance handles, and then do not stop there: add headroom for a spike, and add enough that losing an availability zone or a region does not leave the survivors saturated. Two regions each running at 60% cannot absorb one failing. That is a capacity error, not an availability one, and it is a known pattern behind real outages.
Autoscaling is the standard answer and it deserves its caveats. It reacts, so it is always behind a sudden spike: a scale-up that takes three minutes does not help with a spike that arrives in thirty seconds. It scales the wrong thing if your bottleneck is the database, where adding application servers adds more connections and load and makes things worse. And it can scale you into a much larger bill during an incident or an attack, so it needs an upper bound. For predictable peaks, scaling on a schedule is simpler and works better.
The cost levers worth naming, roughly in order of how much they usually move the number: cache more, so expensive backends are hit less; put a CDN in front of anything served repeatedly; set a retention policy and move old data to a colder tier; compress and choose a compact format for anything stored in bulk; batch small operations into larger ones where you are billed per request; and buy reserved or committed capacity for the baseline while leaving on-demand for the peak.
One framing that lands well in an interview: cost per unit of business value. Cost per active user per month, per video minute served, per thousand API calls. A total is hard to judge; a unit cost tells you immediately whether the design is sane and whether it gets better or worse as you grow. If your cost per user rises with scale, something in the design is superlinear and that is worth finding.
- Designing at scale and never mentioning what it costs.
- Optimising a line that is 3% of the bill while ignoring the one that is 80%.
- Autoscaling with no upper bound, so an attack becomes a bill.
- Sizing regions so that the survivors cannot absorb a failure.
- Forgetting egress and cross-region transfer entirely.
The capacity planning follow-up an interviewer will ask
"This design stores 500 TB of video and serves 10 PB a month. What does it cost, and what would you change?"
The shape matters more than the exact figure, so let me do it roughly. Storing 500 TB in a hot tier is order of ten thousand dollars a month, and dropping the raw originals to a cold tier after 30 days removes much of that, because the originals are rarely read again. Only the transcoded renditions are. That is real money for a policy change. But the storage is not the problem. Serving 10 petabytes a month at internet egress rates is order of a million dollars a month, so bandwidth is something like 99% of this bill and everything else is a rounding error. So there is only one thing worth optimising, and it is not storage. What I would change: put a CDN in front, which is the biggest lever, because CDN egress is cheaper than origin egress and, more importantly, a 95% hit rate means the origin serves a twentieth of the traffic. Then negotiate committed volume, which at petabyte scale is a real discount rather than a rounding one. Then attack the bytes themselves: better codecs cut the same video by a third or more for the same perceived quality, and adaptive bitrate means people on small screens are not served the largest rendition. Each of those is a percentage off the dominant line, which is worth far more than anything I could do to compute or storage. The general point I would make is that I found the dominant line first and then only worked on that.
Your turn
You run two regions, each running at 70% of its capacity at peak. What breaks when one region fails, and what should the number have been?
Learn it from the source
This page gets you interview-ready. These take you to where the idea is actually specified or measured — read them when you want the real depth.
- Reliability and constant work ↗Designing so load spikes do not change how much work the system does.