We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Reliability & Resilience
Estimating future resource needs based on current usage trends and expected growth. Answers questions like 'how many servers do we need for 10x traffic in 6 months?'
In short
Capacity planning is the practice of measuring how much load your system handles today, forecasting how that load will grow, and deciding how much compute, memory, storage, and network you need to provision so the system stays fast and available as demand rises. It answers questions like "how many servers do we need to survive 10x traffic in six months without breaking our latency target?"
In short
Capacity planning is the practice of measuring how much load your system handles today, forecasting how that load will grow, and deciding how much compute, memory, storage, and network you need to provision so the system stays fast and available as demand rises. It answers questions like "how many servers do we need to survive 10x traffic in six months without breaking our latency target?"
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Capacity Planning across a run of lessons, not one page. These 4 alone are about 92 minutes of step-by-step reading, every one with a quiz.
Forecast resource needs before you run out, load testing, traffic modeling, and growth projection.
Simulating realistic user traffic to verify your system handles expected load without degradation.
How a GSLB decides which region a user reaches, and why the decision takes minutes to arrive even when it is made in microseconds.
Practical ways to reduce network latency in cloud systems, from region choice and CDNs to protocol tuning. Includes a decision tree to pick a fix.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Capacity Planningpay once,
yours for life
Every service has a ceiling. A database can take only so many writes per second, a web server can hold only so many open connections, a disk fills up. Capacity planning is the work of finding those ceilings, watching how fast you are approaching them, and adding headroom before you hit them. It turns a vague worry like "are we going to fall over during the sale?" into a number you can act on.
The output of capacity planning is concrete: an instance count, a database tier, a storage allocation, an autoscaling minimum and maximum. You start from a measured baseline (requests per second, CPU utilization, memory, IOPS, queue depth), you attach a growth assumption (10 percent month over month, or a Black Friday spike of 8x), and you size resources so that even at peak you stay under a chosen utilization target with room to spare.
It is different from scaling. Scaling is the mechanism that adds or removes resources. Capacity planning is the decision about how much you need and when, so that scaling has the right limits set and the budget exists to back it.
You begin with a service level objective, because capacity only means something relative to a promise. A common one is "p99 latency under 200ms" or "availability of 99.95 percent." You then load test or analyze production data to find the throughput at which you start violating that objective. That breaking point is your real capacity, and it is almost always lower than the theoretical maximum of the hardware.
A useful rule of thumb is the utilization target. Most teams plan to run steady state CPU around 50 to 70 percent, not 95 percent, because queuing theory says latency climbs sharply as a resource approaches saturation. Run a single server at 90 percent CPU and a small traffic bump pushes response times off a cliff. The gap between your target and 100 percent is your buffer for spikes, deploys, and one failed node.
Forecasting takes the baseline and projects it forward. Simple linear projection works for steady growth. For seasonal or bursty traffic you model the peaks directly: a retailer sizes for Black Friday, not for an average Tuesday. You also account for the N plus 1 or N plus 2 rule, provisioning enough that you can lose one or two nodes (or an entire availability zone) and still serve peak load. Headroom plus redundancy plus growth gives you the final number.
You need real capacity planning when running out of capacity is expensive: a checkout flow during a sale, an API with contractual SLAs, a stateful database that cannot be scaled in seconds. Cloud autoscaling does not remove the need. Autoscaling reacts to load, but it has limits you must set, it takes time to boot new instances, and some resources (database connections, a primary database, a third party rate limit) do not scale elastically at all.
The core trade-off is cost versus risk. Over-provision and you pay for idle servers every hour. Under-provision and you risk an outage, dropped revenue, and a paged engineer at 3am. Good planning keeps utilization high enough to be efficient but low enough to absorb the spikes you can predict and the failures you cannot.
The hard parts are forecasting growth you cannot see (a feature goes viral) and planning for resources that scale slowly. A stateless web tier can autoscale in a minute, but adding a read replica or resharding a database can take hours or days, so those need the longest lead time and the most conservative buffer.
Say your API serves 2,000 requests per second at peak today, growing 8 percent per month, and each instance comfortably handles 500 requests per second while staying under your 200ms p99 target. Today you need 4 instances at the limit, so for headroom you run 6, keeping each about 67 percent (2,000 / 6 = 333 of 500). In six months your peak is roughly 3,200 requests per second, which needs about 7 instances at the limit, so you plan for around 10 to keep the same buffer.
Now add failure tolerance. If you run across three availability zones and want to survive losing one, you size each zone to carry half the load, pushing the fleet higher still. You set the autoscaling minimum at the steady state count and the maximum above your forecasted peak, and you revisit the numbers every month against actual traffic so the plan does not drift from reality.
Netflix
Pre-scales its AWS fleet ahead of predictable evening viewing peaks and big launches, sizing well above average load so that losing an entire availability zone does not degrade streaming.
Amazon retail
Plans capacity months ahead for Prime Day and Black Friday, provisioning for traffic many times the daily baseline rather than relying on reactive scaling alone.
Google SRE
Treats capacity planning as a core SRE discipline, combining demand forecasting with N plus 2 provisioning so the loss of two clusters still leaves enough capacity to serve peak.
Kubernetes Cluster Autoscaler
Adds and removes nodes based on pending pods, but operators still set node group minimums, maximums, and resource requests, which is capacity planning applied to a cluster.
Capacity planning decides how much you need and sets the limits and budget. Autoscaling is the mechanism that adds or removes resources within those limits. Autoscaling still depends on good planning because it has minimums, maximums, boot delays, and some resources like a primary database do not scale elastically.
Because latency climbs sharply as a resource nears saturation. Past roughly 70 to 80 percent utilization, queuing means small traffic bumps cause large response time spikes. The gap below 100 percent is your buffer for spikes, deploys, and a failed node, so most teams target 50 to 70 percent steady state.
N plus 1 means you provision enough capacity to handle peak load even after losing one node or zone. N plus 2 tolerates losing two. You size each remaining unit to absorb the failed one's share of traffic, which is why redundant systems need more total capacity than raw demand suggests.
It depends on lead time. Stateless web tiers autoscale in minutes, so a short horizon is fine. Resources that scale slowly, like database replicas, shards, or reserved cloud capacity, need weeks or months of lead time, so plan those conservatively and well in advance.
A service level objective such as a latency or availability target, a measured baseline of current load (requests per second, CPU, memory, IOPS), the throughput at which you start violating that objective, and a growth or peak forecast. From those you derive instance counts, tiers, and autoscaling limits with headroom built in.
Auto Scaling
Automatically adding or removing compute instances based on current demand. Scales out during traffic spikes and scales in during quiet periods to save cost.
Metrics
Numerical measurements collected over time that describe system behavior: request rate, error rate, latency percentiles, CPU utilization. Prometheus is the standard collector.
Throughput
The number of operations a system can handle per unit of time. Think of it as how many cars a highway can move per hour.
Chaos Engineering
Deliberately injecting failures into a system to test its resilience. Netflix's Chaos Monkey randomly kills servers to ensure the system survives.
Back Pressure
A flow control mechanism where a slow consumer signals upstream producers to slow down. Prevents systems from being overwhelmed by data they can't process.
SLI
Service Level Indicator: a quantitative measure of service behavior, like the proportion of requests faster than 300ms. The raw metric that feeds SLOs.
This page explains the idea. The "Capacity Planning" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Capacity Planning lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Capacity Planning in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
