For a peak-driven resource you forecast the *peaks*, not the average: isolate the recurring peak values (Flickr's were Mondays) and trend that series forward. The worked web-server example: 15 servers, ~900 busy Apache processes at peak → 60/server → ~66% CPU; the CPU-to-process multiplier was 1.1. Trending the weekly peaks forward predicted ~1,300 processes in 8 weeks → ~1,430% cluster CPU. At an 85% per-server ceiling that needs 1,430/85 = 16.8 → round up to 17 servers → add 2. A separate calculation showed current capacity (15 × 85% = 1,275% CPU ≈ 1,160 processes) runs out in 3–4 weeks. The forecast then reads cleanly: "out of capacity in 3–4 weeks; need 2 more servers for the load expected in 8 weeks" — a justification grounded in trend data, not a guess. The translation chain (peaks → resource units → servers, minus safety margin) is the reusable pattern. --- *Source: [[The Art of Capacity Planning]] (John Allspaw, O'Reilly 2008) — Ch 4 — Predicting Trends*