Designing High‑Concurrency Systems: From Single‑Machine Optimizations to Distributed Architecture

Introduction

In modern internet applications, the three "high" requirements—high concurrency, high availability, and high performance—are essential, especially for large‑scale platforms like JD during major sales events.

1. Single‑Machine Dimension

Two aspects are considered: hardware upgrades (CPU, memory, network) and code‑level optimizations. A common misconception is that multithreading alone can dramatically improve performance; in reality, it only helps utilize CPU cores and may increase context‑switch overhead.

Example: batch order interfaces that spawn thread pools improve latency under low load but cause severe TP99 growth under high load. Asynchronous methods (e.g., Java CompletableFuture ) provide better response times but increase design complexity.

2. Multi‑Machine Dimension

Horizontal scaling via load‑balanced clusters (expansion) and vertical scaling through micro‑service decomposition (domain‑driven design, CQRS) address high‑concurrency demands. Distributed challenges such as circuit breaking, rate limiting, and timeout handling must be considered.

3. Vertical Dimension

Focuses on database and business‑application layers. Relational databases (MySQL) require sharding and read‑write separation (e.g., using Elasticsearch for reads) to handle massive traffic while maintaining data consistency.

4. Practical Inventory Scenario

High‑read/write sales events cause frequent stock checks and updates, leading to potential overselling. Simple lock‑based approaches on MySQL become bottlenecks under high QPS.

Solution: cache reads with Redis and perform asynchronous stock updates to MySQL, reducing database load.

5. Advanced Architecture

Introduce partitioning of stock across Redis clusters, each partition acting like a Kafka partition. A scheduler registers partitions, tracks remaining stock, and selects partitions via random or round‑robin strategies.

Each partition contains two sub‑domains (active and standby). When the active sub‑domain’s stock falls below a threshold, it switches to the standby, and a background task replenishes the exhausted sub‑domain, preventing data skew.

Asynchronous stock updates are queued via MQ. Two triggers fire: when a partition’s detail log exceeds a threshold, or periodically (e.g., every second). Idempotent processing ensures consistency.

Pre‑allocated stock pools combine with actual inventory to form the effective stock count, and the system continuously synchronizes Redis and MySQL to maintain accuracy.

Conclusion

The presented methodology blends theory and practice: using caching, asynchronous pipelines, partitioned Redis, and a dedicated scheduler to achieve high concurrency while preserving data consistency and enabling horizontal scalability.