Capacity Planning: Don't Run Out of Room

WHY IT EXISTS Capacity planning exists to prevent systems from failing due to insufficient resources when demand changes. It's the proactive process of managing compute, storage, and network resources to meet business goals and user expectations, avoiding costly outages and performance degradation.

THE MENTAL MODEL Think of a highway. Its 'design capacity' might be 2,000 cars per hour per lane in perfect weather. Its 'effective capacity' on a rainy day with an accident is far lower. Capacity planning for software is about planning for the rainy day, not the perfect one. It's the discipline of understanding and provisioning for your system's real-world limits, not its theoretical maximums.

HOW IT WORKS The process involves measuring current performance and resource utilization, then forecasting future demand based on business projections or historical trends. You model how your system will behave under that increased load to identify potential bottlenecks. The key is distinguishing 'design capacity' (the max work possible in a perfect world) from 'effective capacity' (the max work possible given real-world constraints like quality problems, delays, and dependencies). You then provision resources to meet the forecasted 'effective' demand, plus a safety buffer.

WHEN TO USE IT Capacity planning is a continuous process for any production system with a service-level agreement (SLA). It is especially critical before predictable high-traffic events like a product launch, a major sale, or a marketing campaign. It is also a core part of long-term architectural planning and budgeting for cloud infrastructure.

WHEN NOT TO USE IT It's less critical for non-production environments or internal tools with a small, fixed number of users. For highly elastic, serverless architectures that scale automatically, the focus may shift from pre-provisioning capacity to managing cost and setting scaling limits. However, even then, you must plan for the capacity of stateful downstream dependencies like databases that may not scale as easily.

ONE CANONICAL EXAMPLE An e-commerce site planning for a flash sale. The 'design capacity' might be 10,000 checkouts per minute, based on load testing individual services in isolation. However, the 'effective capacity' might only be 4,000 checkouts per minute when the whole system runs together, due to payment gateway latency and database contention. A good capacity plan provisions for the 4,000/min rate plus a safety margin, and includes a strategy for graceful degradation if demand exceeds that.