Capacity Planning

The Question

 "How many nodes do we need for launch?"

 capacity planning turns estimates into provisioned reality:

 inputs:
   expected load      (rps, concurrent users, data growth)
   per-unit capacity  (what one node serves, measured)
   safety margins     (peak factor, headroom, N+1 redundancy)

 output:
   node counts, instance sizes, budgets — with the math shown

The Core Formula Chain

 1. average load
      avg_rps = daily_requests / 86,400

 2. peak load
      peak_rps = avg_rps × peak_factor     (2–5x typical)
      use observed diurnal curves when you have them

 3. required capacity
      nodes = ceil( peak_rps / per_node_capacity × redundancy )

 worked example (RideShare trip lookups):
   140M lookups/day → avg ≈ 1,620 rps
   peak_factor 3    → peak ≈ 4,860 rps
   one node measured at 900 rps sustainable
   N+1 redundancy   → nodes = ceil(4860/900) + 1 = 7 nodes

Measure Per-Unit Capacity Honestly

 per_node_capacity comes from LOAD TESTS at production shape,
 not vendor marketing:

 - test realistic payloads and query mixes
 - measure SUSTAINED throughput where p99 stays in budget,
   not max throughput where latency dies (queuing lesson!)
 - include cold-start behavior and cache-warm state separately
 
 a node that does 2000 rps at 800ms p99 serves ZERO users
 happily. budget to the latency SLO, not to saturation.

Headroom Rules

Margin	Purpose	Typical
Peak factor	Diurnal spikes	2–5× average
N+1 redundancy	Survive node loss at peak	+1 node minimum
Utilization cap	Stay off queuing cliff	≤60–70% at peak
Growth buffer	Time until next resize	20–50%, reviewed quarterly

 stacking them honestly (not multiplying blindly):
 peak 4,860 rps ÷ (0.65 utilization) ÷ 900 rps/node = ~8.3 → 9
 +1 for failure tolerance → 10 nodes provisioned

Storage and Bandwidth Too

 storage:
   daily_new_GB = records/day × bytes/record × replication
   5-year plan: today's number × growth assumptions
   example: 20M trips × 1KB × 3 replicas = 60GB/day
            → ~110TB over 5 years → provision ~160TB (utilization)

 bandwidth/egress:
   response_bytes × rps × 8 bits → Gbps per tier
   40KB × 5k rps ≈ 1.6Gbps — check NIC and NAT limits!

Scaling Triggers (planning’s runtime twin)

 static plans rot; attach triggers to the plan:
 - cpu sustained > 65% for 15 min        → add capacity
 - p99 latency > SLO × 0.8               → investigate/provision
 - disk > 70%                            → expand before compaction pain
 - replica lag > threshold               → shard review
 
 capacity planning is a LOOP: estimate → deploy → observe
 actuals → recalibrate estimates. the first plan is always wrong;
 make correcting it cheap.

Interview Framing

Back-of-envelope sections of interviews ARE capacity planning. Scored shape: estimate average, apply stated peak factor, divide by a measured-sounding per-node number, round up, mention N+1 and the 70% utilization ceiling — then repeat briefly for storage and bandwidth. Showing the arithmetic beats quoting conclusions; interviewers check the math, not the answer.