How to Accurately Estimate System Capacity and Avoid Performance Disasters

Background

The company holds an annual sports meet with a 2000 m run. Normally 60 participants (40 men, 20 women) compete in groups of 10, requiring at least six races, each lasting 30 minutes. This schedule fits from 3 pm to 6 pm, followed by an award ceremony at 7 pm. This year the 4000 m event was cancelled, increasing 2000 m registrations by 50, causing capacity overload and forcing half the participants to race the following weekend, leading to complaints.

Concept

Capacity design is the process of estimating system capacity using strategic calculations; it is a core skill for architects. The discussion focuses on concurrency as an example, requiring analysis of data volume, concurrent users, bandwidth, CPU, memory, storage, etc.

Analysis Process

Understanding Some Principles

TPS (Transactions Per Second) and QPS (Queries Per Second) measure throughput. Concurrency is the number of simultaneous requests a system can handle. Peak QPS can be calculated using the 80/20 rule: (Total PV × 80%) / (Daily seconds × 20%) . Definitions of PV, UV, throughput, and response time (RT) are provided, along with the relationship QPS = Concurrency / Average Response Time and Concurrency = QPS × Average Response Time .

When to Evaluate System Capacity

Three main scenarios require timely capacity assessment: 1) Temporary traffic spikes (e.g., 618, Double 11, New‑Year promotions); 2) Initial system capacity evaluation before launch; 3) Changes in capacity base when features, data volume, or active users grow, necessitating re‑evaluation and scaling.

Evaluation Steps

Analyze daily total visits (PV/UV) from product, operations, or historical data.

Estimate average QPS by dividing total visits during active hours by the number of seconds.

Estimate peak‑interval QPS using traffic‑curve analysis or the 80/20 rule.

Conduct performance stress testing (e.g., nGrinder, JMeter) to find the single‑instance QPS limit; a response time > 2 s indicates a bottleneck.

Confirm final capacity by comparing peak QPS with instance limits and adding redundancy (e.g., number of web instances).

Case Study

For a book reservation system, using the 80/20 rule: (1,500,000 PV × 80%) / (32,400 s × 20%) ≈ 185 QPS. Concurrency = QPS × Avg RT (0.5 s) ≈ 92.5, rounded to 100. After applying a pessimism/optimism factor, the recommended test concurrency is 200+, with observed response times of 50‑100 ms.

Summary

System capacity evaluation should be performed during temporary traffic spikes, initial launch, and when capacity baselines change. The steps include analyzing total visits, estimating average and peak QPS, stress testing to find instance limits, and adjusting based on redundancy. Proper capacity planning would have prevented the sports‑event scheduling issue described at the beginning.