**Parent Topic**: [[Software/README]] ## Scale Ahead of Demand After data protection, "capacity planning is the second most important responsibility" of a storage professional. Nagwani's habit: "I always try to maintain at least **six months' worth of headroom**." Scaling capacity ahead of demand "reduces stress for you and the application, allows for unexpected spikes, and helps avoid unplanned capital expenditures" — and makes capex/opex and datacenter-space/power/supply-chain planning predictable. ## The Headroom Story At one company, NAS appliances served user files with healthy six-month headroom — until the company began building a cheaper in-house storage engine. Anticipating the switch, they **stopped buying NAS appliances**. Then the engine slipped on bugs *and* the site's popularity exploded, pushing the remaining NAS past its limits. To cope they cut replication frequency (breaching RPO); then a disk failed, RAID reconstruction spiked utilization, and they had to disable reads for *days*. ## The Lesson "Always make sure you have enough capacity to survive spikes in growth, as well as **delays in the timeline of software development**." Had they kept the standard six-month headroom until the new engine was production-proven, "we would have easily weathered this event." Don't draw down your safety margin betting on an unproven replacement — a capacity instance of [[Change Introduces New Forms of Failure]]. Capacity should be based on primary constraints (CPU, memory, I/O, storage), not secondary ones like user count. --- *Source: [[Web Operations]] (Allspaw & Robbins, O'Reilly 2010) — Ch 14 — Storage*