skip to content

Your capacity plan has to cover both steady user growth and a marketing launch that goes live next month. How does forecasting organic growth differ from forecasting launch-driven demand, and how do you provision for each?

level: middleimportance: must knowfreq 62%

answer

  1. two curves, one plan
  2. trends fit history; launches have none
  3. ask marketing for the send schedule
  4. smooth ramp versus step function
  5. forecast cores per request, not requests

basics

~20 s

Organic growth is extrapolated from your own traffic history and arrives smoothly. Launch-driven demand has no history to extrapolate, so its size and timing must come from business inputs and be provisioned before the event, not corrected after it.

solid answer

~50 s

I treat them as two forecasts that get added together. Organic growth comes from my own data: fit a trend to **peak** load over several quarters, expressed in resource units — cores and memory per thousand requests — not raw request counts, because a release that changes cost per request moves capacity without moving traffic. That curve is smooth, so I re-fit it monthly and buy incrementally. Launch demand has no trend to fit; the number comes from marketing and product — how many people are contacted, on what schedule, expected conversion, whether the app pushes a notification to every installed device at once. I convert that into an arrival rate over the arrival *window*, not over the day. Because it arrives as a step, it has to be provisioned ahead of the date and held through the event, with an explicit plan for what gets shed or degraded if the estimate was low.

code

python · 16 lines
python
# Organic: fit growth on observed PEAK load, not average.
peak_qps_now = 3000                 # measured daily peak
monthly_growth = 0.05               # from the last 6 months of peaks
organic_peak = peak_qps_now * (1 + monthly_growth) ** 6      # ~4020 qps

# Launch: a step, derived from business inputs, not from history.
emails = 2_000_000
open_rate, click_rate = 0.25, 0.10
requests_per_session = 20           # a session, not one request
arrival_window_s = 5 * 60           # the send lands in ~5 minutes
sessions = emails * open_rate * click_rate                   # 50,000
launch_peak = sessions * requests_per_session / arrival_window_s  # ~3333 qps

target_peak = organic_peak + launch_peak                     # ~7353 qps
capacity_to_buy = target_peak / 0.60   # size so peak lands at 60% util
print(round(organic_peak), round(launch_peak), round(capacity_to_buy))

go deeper

for a junior

Be ready to say a forecast starts from measured peak traffic rather than average, and that a marketing launch is a separate number that comes from the business, not from the traffic graph.

for a middle

Explain how you fit and re-fit an organic trend on historical peaks, convert requests into resource units such as cores per thousand requests, and turn a campaign's send volume and schedule into an arrival rate over the arrival window.

for a senior

Show judgment about uncertainty: which end of an estimate range you provision to, how far ahead you commit the capacity, and what you have ready to degrade or shed if the launch estimate turns out low.

for a principal

Own the tradeoff between carrying launch headroom for weeks and betting on elasticity, and describe how per-service forecasts roll up into purchasing commitments and a budget across many teams rather than one service.

## Two forecasts, added together Capacity plans usually fail not because the arithmetic was wrong but because one forecast was used where two were needed. Demand comes from two sources with different shapes and different data sources. **Organic growth** is the slow drift of existing usage: more users, more sessions per user, more data per session, more retries as the client fleet ages. It is continuous, it is already visible in your telemetry, and a miss is correctable next month. **Launch-driven growth** (often called inorganic) is an event: a campaign, a partnership going live, a mobile push, a free tier opening, a public on-sale time. It is discontinuous, it is *not* in your telemetry, and a miss is only correctable during an outage. ## Forecasting organic growth Fit the trend to peak load, not average. Provisioning serves peaks; an average hides the daily and weekly shape entirely. Use enough history to see the seasonality that matters — several quarters if the business has a yearly cycle — and fit at the granularity you will actually provision at. A one-minute peak and a one-hour average of the same traffic can differ by a factor of two. Express the forecast in **resource units**, not requests. Measure cost per request (CPU-seconds, memory, database queries, bytes egressed per thousand requests), then forecast demand and cost separately. A release that doubles CPU per request halves your effective capacity with no change in traffic at all, and a request-only forecast will never see it. A fitted trend is only valid while the system that produced it is unchanged. Regime changes break it: a large customer onboarding, a new region, a mobile release that changes call patterns, a client-side retry policy change. When one of those lands, the history before it is a different distribution — re-fit rather than extending the old line. Finally, back-test. Each planning cycle, compare last cycle's forecast to what actually happened and record the error. A forecast whose accuracy nobody tracks is an opinion. ## Forecasting launch-driven demand This is a conversation, not a regression. The useful questions are concrete: - How many people are being contacted, and is the send staggered or all at once? - What did the last comparable campaign convert at? - Does the app push a notification to every installed device? Push produces the sharpest arrival curve there is. - Is there a fixed on-sale time or a countdown? Anything that synchronizes users compresses the whole day's demand into minutes. - How many backend requests does one converted session actually make? Then convert to an arrival rate over the arrival window: ``` sessions = contacted * open_rate * click_rate requests = sessions * requests_per_session peak_rate = requests / arrival_window_seconds ``` The two mistakes that dominate here are dividing by a day instead of by the window, and counting one request per user instead of a whole session. Because the inputs are estimates, produce a range rather than a point. Provision the upper end when the cost of doing so is bounded and the cost of being wrong is an outage, and write down explicitly what you shed or degrade above that line. ## Converting either forecast into what you buy Demand does not become servers directly. It becomes a set of resource requirements — application CPU and memory, database queries per second and connections, cache working-set size, queue throughput, third-party API calls, egress bandwidth — and each of those has its own ceiling. The plan is bound by whichever ceiling is reached first, which is frequently not the application tier. A fleet that can serve 4x traffic in front of a database connection limit sized for 1.5x is planned for 1.5x. ## Provisioning them differently - **Organic:** incremental. Re-check monthly, add capacity on a normal cadence, let long-term commitments cover the part of the curve you are confident about. An error is caught by the next cycle. - **Launch:** a step function. Provision before the date, hold it through the event and its tail, and unwind on a schedule you decided in advance. There is no next cycle during a campaign. ## What goes wrong Extrapolating the trend line through a launch date and assuming the model covers it. Spreading a campaign's demand evenly across a day. Forecasting average rather than peak. Assuming elasticity substitutes for the forecast — it does not, because reactive scaling reacts in minutes while a push notification arrives in seconds. And forecasting requests forever without ever re-measuring cost per request.

  • Marketing tells you the launch will bring '10x traffic'. How do you turn that into a number you can provision against?
    Push back to concrete drivers: how many people are contacted, on what schedule, at what historical conversion, and how many backend requests one session makes. That yields an arrival rate over the actual arrival window and a plausible range. I provision to the upper end of that range when the cost is bounded, and write down what gets shed above it.
  • How do you keep an organic forecast honest after the first month?
    Back-test it. Each cycle, compare the forecast against actual peaks and record the error, then re-fit. Watch specifically for regime changes — a new region, a big customer onboarding, a client release that changes call patterns — because those invalidate the earlier history rather than adding to it.
  • Traffic is flat month over month but a release doubled CPU per request. What does that do to your plan?
    It halves effective capacity with no demand signal at all. This is why forecasts are expressed in resource units: forecast demand and cost per request separately, re-measure cost after significant releases, and treat a jump in cost per request as a capacity event even though the traffic graph is unchanged.

saying these in an interview costs you the question

  • Extrapolating the traffic trend line straight through a launch date
  • Assuming campaign traffic spreads evenly across the day
  • Forecasting average traffic instead of peak
  • Claiming autoscaling absorbs a launch, so no forecast is needed
  • Never comparing last cycle's forecast against what actually happened

context

resolving links…