Designing High‑Concurrency Architecture for Large‑Scale E‑Commerce Applications

Preface

High concurrency frequently appears in business scenarios with a large number of active users, such as flash‑sale events or timed red‑packet collection. To provide a smooth user experience, it is necessary to estimate the expected concurrency and design a suitable high‑concurrency handling solution.

Server Architecture

From the early stage of a single server to mature clustered and distributed services, a high‑concurrency service requires load balancing, master‑slave database clusters, NoSQL cache clusters, and CDN for static files. The basic components are:

Servers Load balancing (e.g., Nginx, Alibaba Cloud SLB) Resource monitoring Distributed deployment

Databases Master‑slave separation, clustering DBA table and index optimization Distributed databases

NoSQL Redis, MongoDB, Memcached with master‑slave clustering

CDN Static assets: HTML, CSS, JS, images

Concurrency Testing

High‑concurrency business needs load testing to evaluate the capacity of the architecture. Third‑party services (e.g., Alibaba Cloud performance testing) or self‑hosted test servers can be used together with tools such as Apache JMeter, Visual Studio Load Test, or Microsoft Web Application Stress Tool.

Practical Solutions

General Scheme

For typical user‑centric operations (sign‑in, user center, orders), cache the data first; if the cache misses, query the DB, then store the result back to the cache. Use hash‑based key distribution to spread users across cache nodes.

Sign‑in: check Redis hash for today’s sign‑in record, fall back to DB if missing, then cache the result.

Orders: cache only the first page (40 items); subsequent pages read directly from DB.

User Center: similar cache‑first approach.

For shared cache data, avoid massive DB hits by updating the cache via an admin backend or locking DB updates.

Message Queue

For bursty write‑heavy scenarios such as timed red‑packet distribution, push user participation information into a Redis list (queue) and let a multithreaded consumer process the queue, thus protecting the DB from overload.

Level‑1 Cache

When connection limits to the cache server become a bottleneck, store hot data in the web server’s own memory (level‑1 cache) with short TTL to reduce cache server load.

Static Data

Static or infrequently changing data can be exported as JSON/XML/HTML files and served via CDN; the application falls back to cache or DB only when the CDN does not have the file.

Other Schemes

Clients can send a version identifier with each request; if the version matches the server’s latest version, the server returns a status code without transmitting the data again.

Layering, Partitioning, Distribution

Large sites should be layered (presentation, service, data), partitioned horizontally into modules (e.g., user service, order service), and deployed in a distributed manner with independent servers, load balancers, and clustered databases.

Clustering

Deploy multiple identical application servers behind a load balancer (e.g., Nginx, SLB) and use master‑slave database clusters to achieve higher concurrency and fault tolerance.

Asynchronous Processing

For DB‑intensive high‑concurrency operations, decouple the request from the DB write by using a message queue; the front‑end responds quickly while a background worker persists data and updates caches.

Cache Design

Cache frequently accessed, rarely changing data in memory stores (Redis, Memcached) or in‑process memory, and use versioning to avoid unnecessary data transfer. CDN caching of static resources further reduces server load.

Service‑Oriented Architecture

Extract common business functions into independent services (SOA/micro‑services). Example: a user‑behavior tracking service built with Node.js, Redis, and MySQL, handling billions of events via asynchronous queues.

Redundancy and Automation

Maintain backup databases and standby servers; automate monitoring, alerting, and failover to reduce manual intervention and ensure high availability.

Summary

High‑concurrency architecture evolves continuously; a solid foundational infrastructure—layered, partitioned, distributed, and automated—facilitates future expansion and reliable service delivery.

Source: https://my.oschina.net/u/3772106/blog/1793561