How do you answer capacity planning and on-call questions?

In this article

1. Before you start
2. Why interviewers ask this
3. Capacity planning and on-call from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is one step of the site reliability engineering interview guide; for the cloud and operations basics behind it, see the DevOps and cloud learning path.

Why interviewers ask this

A service that runs short of capacity pages the people who run it, and a rotation that is too small wears those people out. In our reading, that link is why the two topics are asked together. Candidates report scenarios such as "traffic will rise after a launch; how do you prepare, and who gets paged?" in site reliability and DevOps rounds.

A weak answer says "add more servers and share the pager." A strong answer forecasts demand beyond the time it takes to get capacity, keeps headroom below full utilization, adds redundancy for failures, and sizes the rotation so each engineer is paged rarely enough to fix causes. A Staff-level answer also checks last quarter's forecast against what happened and says what it would change. For the part after the page fires, see how to answer an incident response scenario interview.

Capacity planning and on-call from first principles

Capacity planning

Capacity planning is the practice of forecasting future demand and provisioning enough servers, storage and redundancy to serve it at the required availability, where the forecast must look further ahead than the time needed to acquire capacity, so supply is in place before demand arrives.

Pager load

Pager load is the number of paging incidents that an on-call engineer receives over a typical shift length, such as per day or per week (Google Workbook). It measures how heavy a shift is, as opposed to how long it is, and a team lowers it by fixing the causes of pages.

In plain words

Think of a shop with checkout lanes. A lane that is busy every second has no slack, so one extra shopper makes its line grow. Managers keep some lanes ready and call staff in before a sale starts. On-call is the same idea for people: a rota names who answers the phone when the line gets too long. The analogy breaks in one place. Servers do not tire, but engineers do, so the rota needs a limit on how often each person is paged.

In one precise sentence, capacity planning sets how many workers exist for forecast peak demand plus failures, and on-call sizing sets how many people share the pages that remain.

Step 1: Utilization sets queueing delay, so plan for headroom

A service needs headroom because queueing delay grows steeply as utilization approaches full. Headroom is the spare capacity kept above expected load. Little's Law is the rule that the average number of requests inside a system equals the arrival rate multiplied by the average time each request spends there. At 400 requests per second and 250 milliseconds each, 100 requests are in flight at any time (illustrative inputs).¹

Delay then depends on how close the workers run to full. Take a single server with random (Poisson) arrivals and exponential service times, called the M/M/1 queue, with a capacity of 100 requests per second, so a request needs 10 milliseconds of service (illustrative).

The mean time in the system is 20 milliseconds at 50 requests per second, 50 at 80, 200 at 95 and 1,000 at 99, which is 2, 5, 20 and 100 times the service time.¹ An instance with 10 slots waits less at the same utilization, but the curve has the same shape. Headroom keeps queueing delay bounded. The target utilization that sets it is a number a team chooses and defends from load tests, not a published constant.

Input: arrival rate and time per request. Output: requests in flight and a utilization to stay under. You now know why the plan stops short of full.

Step 2: Forecast demand beyond the lead time

A capacity forecast has two demand inputs and must reach further ahead than the time needed to get new capacity. The forecast must run beyond the procurement lead time, as Google's site reliability engineering book puts it. Organic growth is natural product adoption and usage. Inorganic growth is demand that comes from events such as feature launches and marketing campaigns. A 2020 Google article on capacity management adds that history drives the forecast for an existing service and planned new consumers join it as separate lines.

Regular load testing then maps raw capacity, such as servers and disks, to service capacity. With 400 requests per second today, growth of 8% a month for 3 months and a launch adding 100, the forecast peak is about 604 requests per second (illustrative inputs).¹

Check each forecast against reality: the book says "Divergence implies unstable forecasting, inefficient provisioning, and risk of a capacity shortfall."

Step 3: Add N+2 redundancy and turn the forecast into instances

N+2 redundancy is a configuration in which N instances can serve peak traffic while the two largest instances are unavailable, so a planned outage and an unplanned one can overlap. N+2 serves peak while the two largest instances are down, and Google's capacity-planning best practices allow degraded mode in that case.

Turn the forecast into N. Suppose one instance serves 10 requests at a time at 250 milliseconds each and the team targets 70% utilization (all illustrative). One instance then carries 28 requests per second, so the forecast peak of 604 needs N = 22 and the plan provisions 24.¹ Running every instance at full utilization would need only 16, so the six extra instances in N are the price of headroom.¹

Input: forecast peak, per-instance rate and the redundancy rule. Output: an instance count. Next you size the people who respond when that fleet misbehaves.

Step 4: Size the rotation and the incident budget

An on-call rotation is sized by two separate limits, time share and incidents per shift. Google's site reliability engineers aim to spend at least 50% of their time on engineering; of the rest, no more than 25% of total time goes to on-call and up to 25% to other operational work (Being On-Call). A rotation sized by the 25% rule needs eight engineers, which is the book's minimum for a single site; in our arithmetic, primary and secondary slots on week-long shifts give two slots among eight people, which is 25%.¹ The book gives six per site for a team on two sites.

Quality is the second limit. An incident takes about 6 hours on average once root-cause analysis, remediation and the postmortem are counted (Being On-Call, 2016), so a 12-hour shift fits at most 2 incidents.¹ The Workbook sets the same target of two incidents per shift.

Input: team size and pager load. Output: whether the rotation is sustainable.

1 · Headroom2 · Forecast3 · Redundancy4 · RotationReplay

Step-by-step description

1. Stay below full utilization to bound delay.
2. Forecast demand beyond the lead time.
3. Provision N+2 so peak survives two outages.
4. Size the on-call rotation by the 25% rule.

• Headroom keeps queueing delay bounded.
• The forecast must run beyond the procurement lead time.
• N+2 serves peak while the two largest instances are down.
• A rotation sized by the 25% rule needs eight engineers.

Worked example

The service from the steps carries 400 requests per second today. The table collects every computed value; the inputs marked illustrative are chosen for teaching, and the rest follow from sourced rules.

Delay is the cost of running full. The delay factor, mean time in the system divided by the service time, is 1 divided by (1 minus utilization) in the single-queue model, so it is 2 at 50% utilization and 100 at 99% utilization.¹ Delay multiplies as utilization approaches full.

Text description of the diagram

• The delay factor is 2 at 50% utilization and 100 at 99% utilization.
• Delay multiplies as utilization approaches full.

The availability target also sets how fast on-call must respond. A 99.99% target over a 90-day quarter allows 12.96 minutes of downtime,¹ which matches the "around 13 minutes" in Being On-Call. The Workbook describes 99.98% as roughly 26 minutes per quarter, and the script gives 25.92.¹ With a budget that small, a page that waits half an hour spends the whole quarter.

Trade-offs and edge cases

Capacity and on-call trade cost against safety. More headroom and more redundancy cost money; fewer engineers on the rota cost sleep. Four cases show where the textbook answer bends.

Autoscaling reduces cost but does not replace planning. The Workbook notes that with autoscaling you need not provision for peak load all the time (Managing Load), yet dependencies and storage still need a forecast, and new capacity still has a lead time.

Plans are brittle. Efficiency changes, adoption shifts and delivery dates slip, and resources are not interchangeable: spare capacity on one continent does not fix a shortfall on another when latency forces users to be served locally (Software Engineering in site reliability). Google's answer is to state the requirement, not the implementation.

Small teams still apply the idea. The Workbook's on-call chapter takes up the objection "we are not Google" and says the approach applies at any size. The eight-engineer figure is arithmetic, so a smaller team shows the arithmetic and changes something: fewer pages, a second site, or handing the pager back, which Being On-Call describes as the escape hatch for operational overload.

Alert quality matters as much as team size. Pages should be actionable; noisy alerts should approach one alert per incident (Being On-Call, 2016). To see how the signals behind pages are collected, read monitoring vs logging vs tracing. The same book gives 5 minutes and 30 minutes as typical response times for user-facing and less time-sensitive services. A rotation that is too quiet is also a risk, so it asks that every engineer be on-call once or twice a quarter.

Text description of the diagram

• On-call time share is capped at 25%.
• Incidents are capped at 2 per 12-hour shift.

How to answer it in an interview

The spoken structure: forecast, headroom, redundancy, then rotation size and pager load, and finish with how you check yourself.

Common mistakes

• "We run at full utilization to be efficient." (wrong) Delay multiplies near full. (right) "I pick a target utilization below full and show the delay it avoids."
• "Autoscaling means we need no capacity plan." (wrong) Dependencies, storage and lead times remain. (right) "Autoscaling cuts the cost of peak, and I still forecast for what it cannot scale."
• "More alerts mean better coverage." (wrong) Noisy pages bury real ones. (right) "Pages are actionable and tied to the service level objective."
• "Eight engineers is a Google-only rule." (wrong) The Workbook says the approach applies at any size. (right) "The eight comes from the quarter cap; with fewer I cut pager load or add a site."
• "graphics processing unit (GPU) count follows from model size alone." (wrong) The key-value cache grows with context and concurrency. (right) "I size weights plus cache for the concurrency I expect."

Follow-up questions

How do you do LLM capacity planning for GPUs?

Memory is the model weights plus a key-value (KV) cache in a large language model (LLM), and the cache grows with tokens per request times concurrent requests (VMware sizing guide, 2024). Using its figure of 0.000122 GiB per token for an 8-billion-parameter model, 10 requests of 8,192 tokens need about 10 GiB of cache.¹

The weights are 16 GB (8 billion parameters × 2 bytes at 16-bit precision); the guide mixes GB and GiB, and we treat them as equal here. On a 48 GB card, about 262,000 cached tokens fit, or 32 requests of 8,192 tokens.¹ Throughput also sets the GPU count: measure tokens per second per GPU in a load test and divide the peak token rate by it, subject to the latency target.

How many engineers do you need for 24/7 on-call?

The book gives a minimum of eight for a single site and six per site for two sites, because on-call is capped at 25% of an engineer's time. Show the arithmetic rather than the number.

How often should each engineer be on-call?

Being On-Call asks for teams sized so every engineer is on-call at least once or twice a quarter, so skills stay fresh, and no more than the 25% cap allows.

What do you do when the on-call load is too high?

Measure pager load, remove noisy alerts toward one alert per incident, fix the causes of repeat pages and, if overload continues, hand the pager back to the developers. For the manager's side, see how to build an on-call culture as a manager, and for learning from pages, how to give a blameless postmortem interview answer. The incident response guide covers what happens during a page.

How fast should an on-call engineer respond to a page?

Being On-Call gives typical values of 5 minutes for user-facing services and 30 minutes for less time-sensitive ones, and the service level objective sets the real limit. Browse the site reliability engineering guide for neighbouring questions.

Sources

1. Being On-Call (Site Reliability Engineering, chapter 11) — Google (O'Reilly, 2016), 1 Jan 2016
2. On-Call (The Site Reliability Workbook, chapter 8) — Google (O'Reilly, 2018), 1 Jan 2018
3. Introduction: Demand Forecasting and Capacity Planning (Site Reliability Engineering, chapter 1) — Google (O'Reilly, 2016), 1 Jan 2016
4. Appendix B: Best Practices for Production Services, Capacity Planning — Google (O'Reilly, 2016), 1 Jan 2016
5. Software Engineering in SRE (capacity planning case study) — Google (O'Reilly, 2016), 1 Jan 2016
6. SRE Best Practices for Capacity Management — Google (Quesada Torres and Colish, USENIX ;login:, Winter 2020), 1 Dec 2020
7. Managing Load (The Site Reliability Workbook, chapter 11) — Google (O'Reilly, 2018), 1 Jan 2018
8. LLM Inference Sizing and Performance Guidance — VMware Cloud Foundation blog, 25 Sep 2024