7 Essential Strategies to Build High‑Concurrency Back‑End Systems

High concurrency design can be considered from the following aspects:

Stateless

Splitting

Serviceization

Message Queue

Data Heterogeneity

Cache

Concurrency

1. Stateless

Stateless applications are easy to scale horizontally. In practice, the application itself remains stateless while configuration files retain state, such as reading different configuration files per data center via a configuration center.

2. Splitting

Splitting dimensions include:

System dimension: split by business functions, e.g., product system, shopping cart, settlement, order system.

Function dimension: further split a system's functions, e.g., a coupon system can be divided into creation, claim, and usage services.

Read‑write dimension: split based on read/write ratios, e.g., separate read and write services for a product system, or use database sharding for heavy write loads.

Module dimension: split according to foundational or code‑maintenance characteristics, such as separate databases for basic modules, connection pools, or three‑tier code structures.

3. Serviceization

Serviceization requires automatic service registration and discovery, as well as service grouping/ isolation. Different callers may need isolated service groups to prevent a single high‑traffic system from taking down the whole service. Later, consider rate limiting, black‑/white‑lists, timeout settings, retry mechanisms, routing, and fault compensation.

4. Message Queue

Message queues decouple services that do not need synchronous calls and allow subscription to system events. They enable service decoupling, asynchronous processing, and traffic smoothing, such as order generation, periodic push, and order risk control systems.

When using a message queue, handle message send failures and duplicate consumption. Some queues provide automatic retries; if retries fail, they should notify of the failure, prompting persistent logging, alerts, and downstream data handling. Duplicate consumption must be prevented at the business layer.

Example: during e‑commerce promotions, traffic can surge many times higher than normal, requiring designs that sacrifice strong consistency for eventual consistency, e.g., decrementing inventory directly in Redis, logging the operation, and synchronizing to the database via a worker.

Another example: an order system can store orders in Redis and a queue; Redis serves user‑facing order details, while the queue enhances order intake capacity. A worker later syncs queued orders to the database, and a state machine updates order status upon payment, reflecting changes in both the database and Redis.

Further order system design illustration:

5. Data Heterogeneity

When data volume grows, databases are often sharded, e.g., splitting order tables by order ID. Querying a user's orders then requires aggregating multiple tables, so a "user ID" dimension is created for direct business access. Cross‑database joins can be handled by aggregating related tables into a single database based on a common dimension, a practice known as data heterogeneity.

6. Cache

(1) Browser and app client cache

(2) CDN cache

(3) Application‑level cache

(4) Distributed cache, example:

7. Concurrency

For a read service requiring multiple data sources:

If processed serially, it takes 60 ms. By parallelizing independent calls (e.g., C depends on A and B, D is independent, E depends on C), the total time reduces to 30 ms, doubling performance.

Summary

Content compiled from Zhang Kaitao's "Core Technologies of Billion‑Scale Traffic Website Architecture"; recommended for thorough reading.