Designing High-Concurrency Systems: Architecture, Caching & Scaling

When a large number of user requests hit a business system in a short time, the system must respond quickly and reliably; such a system is a high‑concurrency system. High performance and high availability are essential, and designing such a system involves both technical and business considerations.

Technical perspective

1. System decomposition

Splitting a monolithic application into multiple micro‑services based on its modules reduces coupling and allows each service to be deployed independently. After decomposition, each service can have its own database, enabling higher traffic capacity and allowing targeted measures such as clustering for heavily used modules.

Further splitting the monolith into separate services creates independent deployments, as illustrated below.

2. Caching

In high‑concurrency scenarios most requests are reads. Introducing a cache layer (e.g., Redis) can dramatically improve read speed. Without caching, identical queries from different users repeatedly hit the database, increasing load. After the first query, subsequent requests can be served from the cache, reducing database access and improving overall performance.

Cache usage also introduces challenges such as data consistency, cache avalanche, cache penetration, and cache breakdown. Solutions for Redis‑MySQL consistency are discussed in external resources.

3. Using MQ to smooth spikes

When write operations to the database become a bottleneck, a message queue can buffer write requests, turning synchronous processing into asynchronous handling. This keeps database write load within a reasonable range and prevents crashes under high concurrency.

4. Business‑level database separation

Database I/O has an upper limit. By separating business data into multiple databases, capacity can be multiplied. For example, splitting a single primary database into three business‑specific databases can increase supported connections from 1500 to 4500. As data volume grows, horizontal sharding further distributes large tables across many smaller tables.

5. Read‑write separation

For read‑heavy, write‑light workloads, employing MySQL master‑slave replication to separate read and write traffic improves concurrency and provides high availability; if the master fails, a slave can be promoted.

Business perspective

Traffic can also be reduced by business design. For example, during a large promotion like Double‑11, spreading different product categories across separate days (e.g., maternity goods on day 1, electronics on day 2) distributes load and avoids a sudden spike.

In summary, combining business‑level traffic shaping with technical measures such as service decomposition, caching, MQ, database separation, and read‑write splitting enhances a system’s ability to handle high concurrency, while proper rate limiting and monitoring ensure stability and availability.