Articles

Capacity Planning Interview Questions for Senior Engineers: Traffic, Bottlenecks, and Headroom

Prepare for senior capacity planning interviews with traffic estimates, bottleneck analysis, headroom math, failure scenarios, and worked examples.

A capacity planning interview rarely goes badly because a senior engineer cannot divide requests by servers. It goes badly when the answer sizes only the happy path, treats CPU as the whole system, or picks "30% headroom" without explaining what that margin protects.

This guide gives you a reusable way to answer capacity planning interview questions for senior engineers: translate traffic into resource demand, find the binding bottleneck, reserve capacity for failures and scaling delay, and validate the plan with measurements.

Attempt a question before opening the solution; senior-level performance comes from defending assumptions aloud, not recognizing a finished diagram.

Quick Answer: What Makes a Strong Capacity Planning Interview?

A strong answer follows one traceable chain: demand forecast -> workload shape -> service objective -> resource model -> bottleneck -> failure capacity -> validation. Every number should influence an architecture or operating decision.

Do not begin by guessing a server count. Clarify the time horizon, peak-to-average ratio, request mix, payload sizes, latency and availability objectives, scaling lead time, and required failure tolerance. Then state which values are assumptions and which would come from production telemetry or a load test.

Interview signal	Weak answer	Senior answer
Traffic	Uses average daily traffic	Models sustained peak, burst shape, growth, and regional skew
Capacity	Divides QPS by a guessed per-server number	Uses measured throughput at the target latency and error rate
Bottleneck	Assumes CPU will saturate first	Checks CPU, memory, queues, pools, storage, database, cache, and network
Headroom	Adds an unexplained percentage	Separates forecast error, scaling delay, traffic bursts, and failure capacity
Validation	Stops after arithmetic	Defines load tests, dashboards, alarms, and a recurring reforecast cycle

What Senior Interviewers Are Actually Evaluating

The arithmetic is only the visible layer. Interviewers want to see whether you can connect demand, distributed-system behavior, reliability, and cost. A senior candidate makes uncertainty explicit and knows what evidence would replace an estimate.

Your answer should also distinguish load from capacity. Load is the work arriving: requests per second, bytes per second, events per minute, concurrent sessions, or jobs in a queue. Capacity is the maximum work the system can complete while still meeting its SLO. That qualifier matters because a server that can technically accept 2,000 RPS but misses the p99 latency target above 900 RPS has only about 900 RPS of usable service capacity.

Seniority also appears in the failure model. Autoscaling cannot instantly rescue a saturated database, a full connection pool, a cloud quota, or an eight-minute warm-up. Pre-positioned capacity and overload controls must cover the gap.

A Six-Step Capacity Planning Framework

1. Define demand and its shape

Start with the business unit that drives work: users, transactions, files, messages, tokens, or devices. Convert it into average traffic, then model the peak. A 10-second burst can sometimes be buffered; a four-hour peak must be served.

Separate organic growth from launches, migrations, and campaigns. Google's SRE guidance treats both as forecast inputs; Microsoft recommends using historical patterns and business changes rather than one recent average.

2. Define the service objective

Name the latency percentile, availability target, error budget, durability requirement, and freshness target. Include the workload mix: reads versus writes, cache hits versus misses, small versus large objects, synchronous versus asynchronous work, and ordinary versus premium tenants.

This prevents misleading averages. One image upload can cost more than dozens of metadata reads, while one hot tenant can saturate a shard even when fleet-wide utilization looks healthy.

3. Convert demand into resource units

Estimate compute, memory, storage, network, connections, and queue throughput separately. Little's Law gives average in-flight work = arrival rate x average time in the system. For data, include retention, replication, indexes, metadata, and migration space.

Use benchmarks for per-instance capacity. The meaningful number is not "this VM has 16 cores" but "this service version sustains 650 representative RPS per instance while p95 latency stays below 200 ms and errors remain below 0.1%."

4. Find the binding bottleneck

Capacity is governed by the first constrained resource, not the largest fleet number. The limit might be CPU, memory, garbage collection, disk IOPS, database locks, cache bandwidth, a connection pool, a hot partition, network egress, a third-party quota, or consumer throughput behind a queue.

Look for a throughput plateau accompanied by rising latency or queue depth. If web CPU remains at 35% while requests wait on the database pool, adding web servers can make the database problem worse by creating more concurrent connections.

5. Add explicit headroom and failure capacity

Headroom is not one universal percentage. Reserve margin for forecast error, bursts, warm-up delay, software regressions, maintenance, and the failure scenario required by the SLO.

Model failure mathematically. If a three-zone service must preserve its target utilization after losing one zone, size the two surviving zones to carry the full peak. If that cost is unreasonable, say what degrades: perhaps background jobs pause, nonessential features switch off, or low-priority traffic is load-shed.

6. Validate and repeat

Forecasts are hypotheses. Run ramp, spike, soak, and failure tests with representative requests and data. Use the point where throughput stops scaling linearly or tail latency accelerates as the tested operating boundary.

Capacity planning is a loop, not a launch checklist. Compare forecast demand with actual demand, watch whether software releases change resource efficiency, and re-run benchmarks before seasonal peaks or major launches.

Worked Example: Size a Photo Metadata API

Suppose an interviewer asks you to size a photo service with 12 million daily active users. Assume each active user makes 20 metadata reads and 0.2 uploads per day. Reads have an 8x peak-to-average factor; uploads have a 6x factor. Average metadata responses are 80 KB, average stored photos are 600 KB, and data uses three replicas.

Average read traffic is 12M x 20 / 86,400, or about 2,778 RPS; peak traffic is about 22,200 RPS. Uploads average 28 per second and peak near 167. Ask whether that peak is global or concentrated in one region.

If mean read latency at peak is 120 ms, Little's Law estimates roughly 22,200 x 0.12 = 2,664 in-flight reads. That helps size concurrency, sockets, thread pools, and downstream connection limits. Do not substitute p99 latency for the mean without explaining that it would produce a conservative scenario rather than the mathematical average.

A representative load test shows one application instance can sustain 650 RPS at the target latency. At 100% of that tested boundary, the arithmetic minimum is 35 instances. If the normal utilization target is 60%, you need ceil(22,200 / (650 x 0.60)) = 57 instances.

Now test failure. Losing one of three equal zones leaves 38 instances, or 24,700 RPS of tested capacity. They carry the peak at about 90% utilization. Preserving the 60% target after a zone loss needs about 86 instances, so discuss the trade-off: more idle capacity, temporary higher latency, faster warm-up, or degraded features.

Storage growth is approximately 2.4M uploads/day x 600 KB x 3 replicas = 4.32 TB/day, before thumbnails, indexes, metadata, and safety space. Read egress at the application edge is roughly 22,200 x 80 KB = 1.78 GB/s, or about 14.2 Gbps. If a CDN serves 85% of bytes, origin egress falls to roughly 2.1 Gbps, which changes both cost and origin capacity.

Validate cache misses, database failover, cloud quotas, instance warm-up, memory leaks, and connection churn.

How to Diagnose Bottlenecks Under Load

Start at the user-visible symptom and follow one request. Check throughput, tail latency, errors, saturation, queue age, and retries. Correlate them with deployments and request mix before changing capacity.

CPU-bound: throughput flattens as CPU, run queue, or throttling rises. Profile serialization, compression, locks, and algorithms before scaling. Memory-bound: watch working set, allocation rate, GC pauses, OOM kills, and cache eviction.

Database-bound: inspect slow queries, lock waits, IOPS, replication lag, pool wait, and hot partitions. Read replicas do not solve write contention or a poor partition key.

Queue-bound: backlog age grows when arrivals exceed completions. Check partition count and downstream limits before adding consumers. Network-bound: measure bytes per request, packet loss, NIC throughput, load-balancer limits, and egress.

Retries deserve special attention. When a dependency slows, unbounded retries increase offered load and create a feedback loop. Use timeouts, capped exponential backoff with jitter, circuit breakers, admission control, and load shedding to preserve useful work.

Capacity Planning Questions You Should Practice

"Traffic will double in three months. What do you do?"

Clarify whether the growth is gradual or event-driven, forecast per region and request class, and identify each component's current tested limit. Compare the capacity lead time with the demand curve, then plan quota increases, provisioning, load tests, and a staged rollout before the shortfall date.

"CPU is only 35%, but p99 latency is rising. Why?"

Do not scale blindly. Check queueing, connection pools, database locks, storage latency, cache misses, garbage collection, hot keys, network loss, and a changed request mix. Low average CPU can hide one saturated shard, one single-threaded section, or long I/O waits.

"How much headroom is enough?"

Answer with scenarios, not folklore. Derive margins for forecast error, burst duration, autoscaling delay, maintenance, and required zone or region loss. State the normal utilization target and the degraded operating point separately so the interviewer can see what safety the extra capacity buys.

"Should we autoscale or pre-provision?"

Use autoscaling when the metric predicts work, capacity arrives quickly, and the dependency can scale with it. Pre-provision for sharp known events, long warm-up, scarce accelerators, cloud quota risk, or stateful components. Many production answers combine a warm baseline with autoscaling above it.

"What happens when demand exceeds capacity?"

Protect the system rather than accepting unlimited work. Bound queues, prioritize requests, reject early with clear retry guidance, shed optional work, serve cached or stale data where safe, and cap retries. Define the degraded user experience before the incident.

A Seven-Day Preparation Plan

Day	Focus	What to do
Day 1	Traffic math	Convert users and actions into average RPS, peak RPS, bytes per second, and data growth.
Day 2	Service objectives	Practice defining latency, availability, freshness, and durability before sizing.
Day 3	Bottlenecks	Diagnose one CPU, database, queue, cache, and network saturation scenario.
Day 4	Headroom	Model normal load, a traffic burst, scaling delay, and one-zone failure separately.
Day 5	Validation	Design ramp, spike, soak, stress, and failover tests with explicit pass criteria.
Day 7	Review	Rework the weakest estimate, then prepare one project story about a production bottleneck or scaling decision.

Frequently Asked Questions

Are capacity planning questions part of system design interviews?

Usually, yes. They may appear as back-of-the-envelope estimation, a performance follow-up, a production-readiness review, or a troubleshooting scenario. Senior loops often expect the numbers to influence partitioning, caching, redundancy, autoscaling, and overload behavior.

Do I need exact cloud instance specifications?

No. Use explicit assumptions and say that benchmark data would replace them. Interviewers care more about a coherent model and the right measurements than memorized vendor throughput numbers.

What is the difference between capacity and headroom?

Capacity is the maximum sustainable workload at the required SLO. Headroom is the unused portion reserved for uncertainty, bursts, scaling delay, maintenance, and failures. Raw resources that cannot meet the latency target are not useful capacity.

Should I always use a 30% or 50% headroom rule?

No. A percentage can be a starting assumption, but a senior answer derives it from concrete scenarios. A service with instant horizontal scaling and smooth traffic needs a different margin from a database with long provisioning lead time or a GPU fleet with scarce capacity.

How do I use Little's Law in an interview?

Use L = lambda x W to estimate average work in the system. If 10,000 requests arrive per second and mean time in the system is 0.15 seconds, about 1,500 requests are in flight on average. Explain that tail latency, burstiness, and queue limits still require separate modeling.

Final Takeaway

The best capacity planning answers are not collections of impressive numbers. They are auditable arguments: demand creates work, measurements reveal a limit, reliability defines reserve capacity, and tests validate the result.

Start with Handle Traffic Spikes and Estimate Server Capacity, then browse company-specific interview prep for the loops you are targeting. Write down assumptions, calculate in public, and make every unit of headroom defend a real risk.

Sources and Further Reading

Research note: This guide was checked on August 22, 2026. Capacity assumptions are illustrative; production plans should use current telemetry, benchmarks, quotas, and service objectives.