High-Concurrency Architecture Design and Practices for E‑commerce Systems

Introduction

High concurrency often occurs in scenarios with a large number of active users, such as flash sales or timed red‑packet collection. To ensure smooth operation and a good user experience, we must estimate expected concurrency and design appropriate solutions.

Server Architecture

A service evolves from a single server to clusters and distributed services. A robust architecture includes load balancing (e.g., Nginx, cloud SLB), resource monitoring, distributed deployment, master‑slave database clusters, NoSQL cache clusters, and CDN for static assets.

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

Databases Master‑slave separation, clustering DBA optimizations (indexes, tables) Distributed deployment

NoSQL Redis, MongoDB, Memcache (master‑slave clusters)

CDN HTML, CSS, JS, images

Concurrency Testing

High‑concurrency services require load testing to evaluate the capacity of the architecture. Third‑party services (e.g., Alibaba Cloud performance testing) and tools such as Apache JMeter, Visual Studio Load Test, and Microsoft Web Application Stress Tool can be used.

Practical Solutions

General Solution

Daily user traffic is large but scattered; occasional spikes occur.

Typical scenarios include user sign‑in, user center, and order queries.

Example Scenarios

User Sign‑In for Points Compute user’s hash key and check Redis for today’s sign‑in info. If found, return it; otherwise query the DB, sync to Redis, and if still missing, create a new sign‑in record in a transaction. Cache the result in Redis and return. Handle concurrency issues such as duplicate sign‑ins.

User Orders Cache only the first page (40 items) of orders. Read from cache for page 1, otherwise query DB.

User Center Check Redis for user info; if missing, query DB, cache, and return.

Other Business For shared cache data, consider updating via admin tools or locking DB operations to avoid massive DB hits under concurrency.

Message Queue

For spike activities like flash sales, use a message queue to enqueue user actions and process them with multithreaded consumers, preventing DB overload.

Timed red‑packet collection Push user participation info into a Redis list. Multithreaded workers pop from the list and issue red‑packets.

First‑Level Cache

When cache servers become saturated, a first‑level cache on the application server can store hot data with short TTL to reduce connections to NoSQL caches.

Static Data

Static, infrequently changing data can be exported as JSON/XML/HTML and served via CDN, falling back to cache or DB only when CDN misses.

Layering, Partitioning, Distribution

Large sites need long‑term planning: layer the system (application, service, data layers), partition complex business into modules, and deploy them distributedly.

Layering: separate responsibilities across layers.

Partitioning: split complex domains (e.g., user center) into sub‑modules.

Distribution: deploy each module on independent servers, use load balancers, DB and cache clusters, CDN, and distributed computing.

Asynchronous Processing

Database operations under high load can be offloaded to asynchronous pipelines using message queues, allowing the API to respond quickly while persisting data later.

Caching

Cache hot query data in application memory, Redis, or Memcache; use versioning to avoid unnecessary requests; also cache static assets via CDN.

Service‑Oriented Architecture

Adopt SOA or micro‑services to isolate core functions, improve decoupling, high availability, scalability, and maintainability. Example: a Node.js service for user behavior tracking using Redis list queues and MySQL for persistence.

Redundancy and Automation

Implement database backups, standby servers, automated monitoring, alerts, and failover to ensure high availability and reduce manual errors.

Summary

High‑concurrency architecture evolves continuously; a solid foundation simplifies future expansion and ensures system stability.

Source: http://javajgs.com/archives/6322