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

High concurrency—often described as the three "highs" of high throughput, high availability, and high performance—is essential for modern internet services such as JD.com, where massive traffic spikes during events like 618 demand robust system design.

At the single‑machine level, improvements can be made through hardware upgrades and, more critically, through code‑level techniques. The article clarifies common misconceptions about multithreading and asynchronous methods in Java, noting that multithreading alone cannot dramatically increase throughput on limited CPU cores, while asynchronous processing can improve response time but adds architectural complexity.

Moving to the multi‑machine dimension, horizontal scaling via load‑balanced clusters (capacity expansion) and vertical splitting into micro‑services or CQRS architectures are discussed. Distributed systems introduce additional concerns such as circuit breaking, rate limiting, and timeout handling to maintain robustness under high load.

The vertical dimension focuses on database scaling (sharding, read/write separation with MySQL and Elasticsearch) and business‑application strategies. Effective use of caching and asynchronous workflows, tailored to whether the workload is read‑heavy or write‑heavy, is emphasized.

A concrete e‑commerce scenario—handling flash‑sale inventory—illustrates the pitfalls of naïve locking, which can cause request bottlenecks and potential overselling. Simple Redis caching improves read performance but still suffers from single‑node limits.

To overcome these limits, the article proposes a progressive approach: first, cache reads with Redis and update MySQL asynchronously; second, recognize Redis’s single‑point bottleneck and introduce partitioned inventory storage across a Redis cluster, managed by a partition scheduler.

The advanced design partitions inventory into multiple Redis shards (partitions), each with two sub‑domains that dynamically switch based on stock thresholds, mitigating data skew. An asynchronous MQ‑driven pipeline synchronizes Redis updates back to MySQL, ensuring consistency while supporting horizontal scaling.

In summary, building high‑concurrency systems requires a combination of hardware awareness, careful code practices (multithreading vs async), distributed architecture (horizontal scaling, micro‑services), database sharding, caching, and asynchronous processing, all guided by concrete business requirements and continuous performance monitoring.