Capacity Planning — Term Reference

The ongoing process of matching available organizational resources — people, technology, and infrastructure — to anticipated and actual demand for services. The objective is to have exactly enough supply to meet demand: too little causes application slowdowns and outages; too much wastes money on unused resources. Capacity planning operates across three dimensions simultaneously: (1) people — how many humans the service requires; (2) technology — what software and service architectures can grow and shrink with demand; (3) infrastructure — the underlying compute, network, and storage resources. All three dimensions must be sized appropriately for overall capacity to be correct.

The core equilibrium capacity planning seeks to maintain. Demand is the workload placed on a system — requests, transactions, users, data volume. Supply is the available resources to handle that workload — servers, staff, bandwidth, storage. When demand exceeds supply: application slowdowns, network congestion, service degradation, and eventually outages. When supply exceeds demand: financial waste from unused resources — idle hardware, over-provisioned cloud instances, unnecessary staff. Capacity planning continuously monitors and adjusts the supply side to track the demand side, neither lagging behind (outages) nor running far ahead (waste).

The workforce dimension of capacity planning — ensuring the right number of trained humans are available to deliver services that require human involvement (call centers, IT support, incident response, system administration). The hardest capacity dimension to adjust quickly: scaling up (hiring) requires recruiting, interviewing, onboarding, and training — typically weeks to months before a new hire is fully productive. Scaling down (layoffs or redeployment) has financial, legal, and morale costs. This slow adjustment cycle means workforce capacity planning requires longer forecasting horizons than technology or infrastructure. Strategies that add flexibility: contract staffing, cross-training, outsourcing, and remote work arrangements.

The ability of a technology architecture to grow (or shrink) its capacity to meet changing demand. Not all technologies scale efficiently — some are designed for a fixed workload and cannot expand without fundamental redesign. Scalable technology choices for common service types: web services use load balancers with multiple backend servers (add/remove servers to scale); database services use clustering (multiple SQL servers working together) or partitioning/sharding (splitting a large database across multiple servers); cloud services provide on-demand resources that scale immediately with no hardware procurement. Technology scalability must be designed into the architecture from the beginning — retrofitting scalability into a non-scalable system is expensive and disruptive.

A database scaling technique that divides a single large database into smaller, more manageable segments (shards or partitions) distributed across multiple servers. Each server handles only a portion of the total data — for example, users A–M on one server and users N–Z on another. This reduces the per-server load and increases total throughput beyond what any single database server could provide. Sharding is a form of horizontal scaling for databases. The tradeoff: queries that need to access data across multiple shards require cross-shard joins, adding complexity to the application layer. Sharding is best designed for from the beginning; adding it to an existing non-sharded database is a major engineering effort.

The on-premises hardware and networking equipment that forms the foundational layer for services: physical servers, storage arrays, network switches and routers, power and cooling systems. Physical infrastructure requires a procurement process: identify need, approve budget, order equipment, wait for delivery (days to weeks), receive, rack, cable, configure OS and applications, test, then deploy. It represents capital expenditure — a large upfront investment that depreciates over time. Once purchased, it exists and consumes power regardless of utilization. Long lead times mean physical infrastructure capacity decisions must be made well in advance of when the capacity will be needed. Upgrading physical infrastructure mid-deployment often requires service disruption.

Virtualized compute, storage, and network resources provided on-demand by a cloud provider (AWS, Azure, GCP) and provisioned in minutes via a web console or API. No hardware to purchase, ship, install, or rack. Cloud infrastructure is an operational expense — pay-per-use billing (hourly, per-second) means costs scale directly with consumption. Easy to scale up instantly when demand exceeds expectations; easy to right-size or decommission when demand drops. Particularly valuable for handling unexpected demand spikes — provision additional instances immediately, serve the demand, decommission when it passes. Also valuable for new deployments where usage patterns are uncertain — start small and scale as actual demand becomes clear.

Increasing the capacity of an existing server by adding more resources to it: more CPU cores, more RAM, faster storage, or greater network bandwidth. The same physical or virtual machine becomes more powerful. Advantages: architecturally simple — no application redesign required; provides quick capacity increase without changing how the application is deployed. Limitations: every server has a maximum configuration ceiling; once that ceiling is reached, no more vertical scaling is possible. Physical vertical scaling (adding RAM to a server) typically requires downtime. Also maintains a single point of failure — one bigger server is still one server. Best for workloads that are difficult to distribute: single-instance databases, legacy applications, stateful systems that cannot easily run as multiple instances.

Adding more servers to distribute a workload rather than making one server bigger. Instead of upgrading one web server, you add nine more and put them behind a load balancer — aggregate capacity is the sum of all ten. Advantages: no ceiling (keep adding servers as demand grows, within financial limits); inherent redundancy (if one of ten servers fails, the other nine continue; load balancer routes around the failure); each additional server adds capacity incrementally. Requires: the workload must be distributable — the application must be able to run as multiple independent instances simultaneously. Stateless applications scale horizontally easily; stateful ones require careful architecture. Horizontal scaling is the dominant model in modern cloud, web, and microservices architectures.

The ability of a system to automatically increase or decrease resource allocation in real time based on current demand, without manual intervention. Cloud platforms implement elasticity through auto-scaling groups: define the minimum instances, maximum instances, and scaling rules (e.g., add one instance when average CPU exceeds 70% for 5 minutes; remove one instance when CPU drops below 30% for 15 minutes). When demand rises, the system automatically provisions additional instances; when demand falls, it automatically terminates idle instances. Elasticity resolves the fixed-capacity dilemma: instead of provisioning for peak demand (paying for idle capacity during normal periods) or normal demand (risking outages during peaks), the system automatically scales to match actual demand in real time — paying only for what is actually needed.

The practice of matching the size of provisioned resources to actual usage — neither over-provisioned (wasting money) nor under-provisioned (causing performance problems). Particularly important in cloud environments where it is easy to provision large instances for safety and then leave them running at low utilization indefinitely. Right-sizing involves reviewing actual CPU, memory, storage, and network utilization metrics over time and selecting the smallest (cheapest) resource size that reliably meets the performance requirements. For example: a cloud virtual machine provisioned as a 32-core instance running at 8% CPU utilization could likely be right-sized to an 8-core instance at significant cost savings. Regular right-sizing reviews are a standard cloud cost optimization practice.

The operational practices that make proactive capacity planning possible. Monitoring collects real-time and historical data on key capacity metrics: CPU utilization, network throughput, memory usage, storage consumption, application response times. Monitoring provides early warning when resources are being approached (enabling action before outages occur) and generates the historical data needed for forecasting. Forecasting uses trend analysis, seasonal patterns, and business growth projections to predict when current capacity will be insufficient and when to act. Together, monitoring and forecasting enable organizations to add capacity before it is needed rather than in response to outages — the difference between proactive capacity management and reactive fire-fighting.