High Concurrency Architecture and Practical Solutions for E‑commerce Applications

High concurrency often occurs in business scenarios with a large number of active users gathering at the same time, such as flash‑sale events or timed red‑packet collection. To keep the service smooth and provide a good user experience, the expected concurrency level must be estimated and an appropriate high‑concurrency handling scheme designed.

Server Architecture

As a service matures, its architecture evolves from a single server to a cluster and eventually to distributed services. A robust high‑concurrency service requires load balancing, master‑slave database clusters, NoSQL cache clusters, and static‑file CDN support.

Server

Load balancing (e.g., Nginx, Alibaba Cloud SLB)

Resource monitoring

Distributed deployment

Database

Master‑slave separation, clustering

DBA table and index optimization

Distributed deployment

NoSQL

Redis (master‑slave, clustering)

MongoDB (master‑slave, clustering)

Memcache (master‑slave, clustering)

CDN

HTML

CSS

JS

Images

Concurrency Testing

High‑concurrency business needs load testing using third‑party services (e.g., Alibaba Cloud performance testing) or self‑hosted test servers with tools such as Apache JMeter, Visual Studio Load Test, or Microsoft Web Application Stress Tool to estimate the maximum sustainable request volume.

Practical Schemes

General Scenario : Daily traffic is large but dispersed, with occasional spikes (e.g., user sign‑in, user center, order queries). The recommendation is to prioritize cache reads and fall back to the database only when the cache misses, then cache the result.

Key points include hashing user IDs to distribute cache keys, limiting cache size, and handling concurrency issues such as duplicate sign‑in rewards.

User sign‑in for points

Compute a hash key and look up today’s sign‑in info in Redis.

If found, return it; otherwise query the DB, update Redis, and return.

All DB operations are wrapped in a transaction to avoid duplicate rewards.

User orders

Cache only the first page (40 items) of order data.

Read from cache for page 1, otherwise query the DB.

User center

Similar hash‑key lookup in Redis, fallback to DB, then cache.

Other business

Public cache data must consider high‑concurrency DB hits; use admin‑controlled updates or DB‑level locking.

Message Queue

For spike activities like flash sales, a message queue can decouple user requests from DB writes. Users push participation info into a Redis list; a multithreaded consumer pops items and processes red‑packet distribution, preventing DB overload.

Typical tools: Redis list, custom multithreaded consumer.

First‑Level Cache

When cache servers become a bottleneck, a first‑level cache on the application server stores only the hottest data with short TTL, reducing connections to the NoSQL cache layer.

Example: caching public product data for the app’s home page.

Static Data

For data that changes infrequently, generate static JSON/HTML/XML files and serve them via CDN. Clients request the CDN first; if the file is missing, fall back to cache or DB. After backend edits, regenerate and upload the static files.

Other Strategies

For moderately static data, clients can cache locally and send a version identifier with each request. The server compares versions and returns either a 304‑like status or the updated payload, reducing server load.

(To be continued…)

© Content sourced from the web; original author retains copyright.