Example 1: Retail Peak Season — The Fixed-Capacity Dilemma
An online retailer runs its web storefront on four physical servers. Normal weekday traffic is handled comfortably at 35% CPU utilization. The team knows Black Friday generates 8× normal traffic volume.
Option A — Provision for Peak
Purchase 28 additional servers (32 total to handle 8× traffic). Cost: 28 servers × $8,000 = $224,000 capital expense. These servers sit at ~8% utilization for 50 weeks per year. Annual power/cooling/rack cost on idle servers adds another ~$40,000. Black Friday is handled flawlessly — but $264,000 is spent to handle 2 weeks of peak demand.
Option B — Provision for Normal
Keep 4 servers. Black Friday traffic overwhelms them. Response times climb to 45 seconds. Half of shoppers abandon their carts. The site partially fails at 11 AM. Revenue lost: $1.2M in 4 hours. Emergency cloud provisioning attempted mid-outage — too late to restore confidence before the day ends.
Option C — Cloud Elasticity
Migrate to cloud with auto-scaling. Baseline: 4 cloud instances at normal load. Auto-scaling configured: scale out when CPU exceeds 65% for 3 minutes; scale in when CPU drops below 25% for 15 minutes. Maximum: 40 instances. Black Friday: traffic ramps from 6 AM; 28 instances provisioned automatically by 9 AM; all traffic served within normal response times; by midnight instances scale back to 6. Cost for the day: ~$1,400 in additional cloud compute. No outage. No waste.
Elasticity resolves the fixed-capacity dilemma — pay for normal baseline, auto-scale to handle peaks, pay only for the peak capacity during the hours it is actually needed.
Example 2: Database Sharding — Splitting a Growing User Table
A social platform has grown its user database to 800 million rows. Query performance has degraded significantly — a single server struggles with the index size and concurrent write volume.
Before Sharding — Single Database Server
users_db (single server)
800,000,000 rows
Index size: 180 GB
Concurrent writes: 12,000/sec
Average query time: 890ms ← degraded
800,000,000 rows
Index size: 180 GB
Concurrent writes: 12,000/sec
Average query time: 890ms ← degraded
After Sharding — Four Database Servers
Shard 1: A–F
200M rows
Index size: 45 GB
Writes: 3,000/sec
Query time: 180ms ✓
200M rows
Index size: 45 GB
Writes: 3,000/sec
Query time: 180ms ✓
Shard 2: G–M
200M rows
Index size: 45 GB
Writes: 3,000/sec
Query time: 180ms ✓
200M rows
Index size: 45 GB
Writes: 3,000/sec
Query time: 180ms ✓
Shard 3: N–S
200M rows
Index size: 45 GB
Writes: 3,000/sec
Query time: 180ms ✓
200M rows
Index size: 45 GB
Writes: 3,000/sec
Query time: 180ms ✓
Shard 4: T–Z
200M rows
Index size: 45 GB
Writes: 3,000/sec
Query time: 180ms ✓
200M rows
Index size: 45 GB
Writes: 3,000/sec
Query time: 180ms ✓
The tradeoff: Queries that touch a single user's record route to one shard — fast. Queries that need to aggregate data across all users (e.g., "count all users by country") must query all four shards and merge results in the application layer — more complex. This cross-shard join complexity is why sharding must be designed for from the beginning; retrofitting it after the fact requires rewriting large portions of the application.
Sharding is horizontal scaling for databases. It distributes data — not just queries — across multiple servers, reducing per-server load and enabling throughput beyond any single server's limit.
Example 3: Physical vs. Cloud Provisioning — Speed Contrast
Two organizations both discover on the same Monday morning that they need 10 additional application servers to handle unexpected growth. One runs on-premises; one runs in the cloud.
| Step | On-Premises Organization | Cloud Organization |
|---|---|---|
| Day 1 | Identify need, write justification, submit purchase order for approval | Log into cloud console; launch 10 new instances; takes 8 minutes |
| Day 2–3 | Finance approval process | Servers already serving traffic; auto-scaling configured to handle further growth |
| Day 4–7 | Vendor procurement, order confirmation, estimated 2-week delivery | — |
| Day 14–18 | Hardware delivered; schedule datacenter access; rack and cable 10 servers | — |
| Day 19–21 | OS installation, configuration management, application deployment | — |
| Day 22 | Testing and validation before production deployment | — |
| Day 23 | Servers live in production — 23 days after identifying the need | Already handled for 22 days; no delay, no degradation |
Cloud infrastructure decouples capacity decisions from procurement lead times. The difference between identifying a need and having capacity is minutes in the cloud, weeks on-premises — which fundamentally changes how much advance notice forecasting must provide.
Example 4: Vertical vs. Horizontal Scaling Decision
A startup's API server (stateless, handles REST requests) and its payment processing database (stateful, single-instance, complex transactions) both need more capacity.
API Server — Horizontal Scaling (correct choice)
The API server is stateless — each request is independent, no session data stored on the server itself. Adding a load balancer with 5 API server instances distributes the load evenly. Capacity is now 5×. If any server fails, the load balancer routes around it automatically. Adding more servers in the future requires no architectural change — just add to the pool. No ceiling.
API Server — Vertical Scaling (wrong choice)
Upgrading the single API server to a 64-core instance handles more load — but it is still one server. If it fails, the entire API is down. Once the largest available instance is reached, no further scaling is possible. The single point of failure is preserved at higher cost.
Payment Database — Vertical Scaling (correct initial choice)
The payment database uses complex multi-table transactions and was not designed for multi-instance deployment. Horizontal scaling would require significant re-architecture. Vertical scaling — adding more RAM (from 64 GB to 256 GB) and faster NVMe storage — provides immediate capacity relief without touching the application code. Buys time for the team to properly design a clustered or sharded replacement if needed long-term.
Stateless services scale horizontally easily. Stateful services often require vertical scaling as the first step, with horizontal scaling designed into the next architectural iteration.
Example 5: Comprehensive Scenario — Healthcare IT Capacity Planning
A regional hospital network is deploying a new patient portal that will be used by 400,000 patients. The IT team must plan capacity across all three dimensions.
People Dimension
Demand analysis: Patient portal requires a support desk for password resets, navigation help, and account issues. Historical data from a similar portal at a sister hospital: ~2% of users contact support in the first 90 days. 400,000 × 2% = 8,000 support contacts. Peak anticipated in weeks 2–4 post-launch at ~500 contacts/day.
Capacity decision: Each support agent handles ~80 contacts/day. Peak staffing needed: 500 ÷ 80 = ~7 agents. Current team: 3 agents. Gap: 4 agents. Hiring timeline: 8 weeks minimum. Launch is in 10 weeks — barely enough time. Decision: hire 2 permanent agents now, contract 2 temporary agents for the 90-day peak period.
Capacity decision: Each support agent handles ~80 contacts/day. Peak staffing needed: 500 ÷ 80 = ~7 agents. Current team: 3 agents. Gap: 4 agents. Hiring timeline: 8 weeks minimum. Launch is in 10 weeks — barely enough time. Decision: hire 2 permanent agents now, contract 2 temporary agents for the 90-day peak period.
Technology Dimension
Web tier: Portal web servers deployed behind a load balancer with auto-scaling. Minimum: 2 instances (redundancy). Maximum: 12 instances. Scale-out rule: CPU > 70% for 5 minutes. Scale-in rule: CPU < 25% for 15 minutes. Load balancer performs health checks every 30 seconds; automatically removes failed instances.
Database tier: Patient records database cannot be sharded easily (existing application, complex queries). Decision: vertical scaling — upgrade to the largest available cloud database instance (32 vCPU, 256 GB RAM). Read replicas added for report queries to offload the primary.
Database tier: Patient records database cannot be sharded easily (existing application, complex queries). Decision: vertical scaling — upgrade to the largest available cloud database instance (32 vCPU, 256 GB RAM). Read replicas added for report queries to offload the primary.
Infrastructure Dimension
Cloud-based: Web tier fully elastic in cloud — handles launch spike and scales back afterward. Database tier on cloud managed database service — easier right-sizing over time as actual usage is measured.
Monitoring configured: Alerts at 70% CPU, 80% memory, 85% storage, 500ms average response time. Weekly right-sizing review scheduled for 90 days post-launch to right-size instances based on actual measured utilization.
Monitoring configured: Alerts at 70% CPU, 80% memory, 85% storage, 500ms average response time. Weekly right-sizing review scheduled for 90 days post-launch to right-size instances based on actual measured utilization.
Outcome
Launch day: 12,000 users access the portal in the first 4 hours. Web tier auto-scales from 2 to 7 instances by 10 AM; scales back to 3 by 6 PM. Support contacts peak at 480/day in week 3 — within the staffed capacity. At 90-day review: 5 of 12 max web instances ever used; right-sized maximum to 6. Database running at 45% CPU — right-sized to a smaller instance, saving $1,800/month.
Effective capacity planning spans all three dimensions simultaneously. Missing any one — not enough support staff, unscalable technology, or under-provisioned infrastructure — degrades the overall service regardless of how well the other dimensions are handled.