Understanding High Concurrency, High Availability, Performance, and Scalability: Concepts and Metrics

Recently I organized concepts and technologies related to high‑concurrency systems and wrote this article to provide a systematic summary, benefiting others and inviting interested peers to discuss (WeChat: selfimpr).

What is the relationship among high concurrency, high availability, high performance, and high scalability?

Product, market, and operation success brings massive simultaneous user traffic, which is the high‑concurrency scenario. High concurrency itself is not a technique but a technical challenge that requires the system to maintain error‑free and ultra‑fast responses.

To move from qualitative to quantitative analysis, we need three perspectives: availability, performance, and scalability.

Availability aims to minimize errors or reduce loss when errors occur. Performance aims to let as many users as possible obtain responses in the shortest time. Scalability aims to support availability and performance while allowing low‑cost adjustments when the system structure must change.

Availability Metrics and Decomposition

The availability metric is the proportion of uptime in total runtime, often expressed as "N‑of‑9s". Since this metric is not actionable, it is broken down by analyzing unavailable time.

Unavailability originates from five types of changes:

Human‑related changes, such as marketing activities that cause sudden traffic spikes without technical coordination.

Upstream/downstream changes, like a sudden increase in requests from an upstream service or a rise in failure rates of downstream services.

Environment‑related changes, including hardware maintenance, CPU, network, or I/O resource usage fluctuations.

Time‑related changes, e.g., integer timestamps nearing overflow, certificate expiration, or time‑partitioned table creation.

System‑iteration changes, which are naturally perceived during development cycles.

Reducing Fault Ratio through Prediction

Once a change is detected, we can predict potential faults based on experience and mitigate them. Common mechanisms include CodeReview, release review, case studies, QA testing, and other systematic practices.

Minimizing Fault Impact

Faults are inevitable, so architecture should limit their impact. Techniques include resource isolation (so failure of service A does not affect service B), read‑write separation, data isolation (e.g., per‑region game servers), canary releases, rate limiting, and circuit breaking.

Accelerating Fault Recovery

Rapid recovery requires on‑call duty to intervene immediately, prepared rollback plans for releases, and automation for predictable fault points (e.g., automatic failover or scaling).

Performance Metrics and Decomposition

Performance is measured by task completion time, with common indicators such as average response time, percentile response time, QPS, and TPS. Task time consists of CPU, memory I/O, network I/O, disk I/O, and waiting time.

Optimization can be approached from three angles:

Improve resource utilization through code optimization or increased parallelism.

Trade past or future time for current time via caching, pooling, pre‑compilation, or asynchronous processing.

Replace slow resources with faster ones, e.g., caching disk data or computation results.

Scalability Metrics and Decomposition

Scalability focuses on the cost‑benefit trade‑off. Its value is quantified, while its cost includes manual refactoring and automated deployment. Choosing the right timing to invest in scalability should balance added value against added complexity, possibly using financial metrics.

Summary

1) High concurrency is the scenario we face. 2) User experience—error‑free and ultra‑fast response—is the problem to solve. 3) Availability, performance, and scalability are quantitative lenses to address user experience. 4) Availability decomposition: change count, fault‑inducing proportion, fault impact, fault duration. 5) Performance decomposition: resource usage time + resource waiting time, with optimization via utilization, time‑trading, and fast‑resource substitution. 6) Scalability decomposition: cost‑benefit analysis and timing selection.

The purpose of this article is to clarify concepts and provide a systematic summary; specific technical discussions should be tailored to concrete scenarios. Feel free to add me on WeChat (selfimpr) for further exchange.