Peak Traffic

Why Averages Are the Dangerous Number

Average QPS describes a system nobody uses. Real traffic clusters into shapes, and capacity must absorb the shape’s top — because users experience peaks, and outages happen at peaks:

 requests/min across a day (consumer pattern)

  ▲                                ╭────╮  ← evening peak
  │                        ╭──╮    │    │
  │              ╭─╮       │  ╰────╯     ← midday bump
  │        ╭─────╯ ╰───────╯
  │────────╯                              ← overnight trough
  └────────────────────────────────────────► time
  
 average sits in the middle of nowhere useful:
 peak : average ≈ 2.5x typical weekday, 4x+ weekends/events

Sizing for average means failing daily between 7–10pm.

The Peak Factor Method

 peak capacity requirement = average QPS × peak factor

 RideShare: 1,400 rps average × 2.5 = 3,500 rps rider traffic
            provision to ~4k rps (rounding + headroom)

Choosing the factor honestly:

Traffic character	Typical factor
Global user base (time zones smooth the curve)	1.5–2x
Single-region consumer app	2–3x
Event-driven (ticket sale, flash sale, product launch)	10–100x

Global smoothing is why worldwide platforms run deceptively flat curves; regional apps wear their local dinner hour openly.

Spike Events: The Other Peak

Diurnal peaks are predictable; events are peaks with no schedule:

 TICKET DROP / FLASH SALE SHAPE

 ▲                    ██
 │                    ██     50–100x average for minutes,
 │                 ████      then gone
 │              ████████
 └───────────────────────────►

 architectures that serve this:
 - queue-based load leveling (admit, don't melt)
 - precomputed/static rendering where possible
 - autoscaling is TOO SLOW alone — reactive scale takes minutes;
   spikes take seconds. pre-provision or shed load deliberately.

The design answer differs by shape: diurnal peaks → autoscaling + scheduled capacity; event spikes → admission control + graceful degradation + pre-warmed caches.

Sizing Consequence

Every downstream estimate inherits the peak factor:

 servers   sized on peak QPS ÷ per-node capacity
 databases sized on peak connections + peak write rate
 caches    sized on peak working set
 cost      optimized against AVERAGE utilization (the tension of lesson 11)

This is the fundamental capacity economics loop: provision for peak, pay for average, minimize the gap — autoscaling narrows it, reserved baseline covers the floor.

Interview Framing

Interviewers test this implicitly (“does your design survive 8pm?”) and explicitly (“what happens when a celebrity causes a 20x spike?”). Strong answers separate the two peak types, name the mechanism per type, and re-run one number through the peak factor live. Saying “autoscaling will handle it” without addressing reaction lag is the classic junior tell.