How to Design High-Concurrency Systems: Practical Strategies and Real-World Examples

1. What Is High Concurrency?

High concurrency refers to a large number of users accessing the same URL at the same moment, such as during e‑commerce flash sales or DDOS attacks. It can cause server crashes, data duplication, and a poor user experience.

Consequences

Server side: resource exhaustion, duplicate records, inconsistent data.

User side: slow response, frustration.

Practical experience: activities like sign‑in, lottery, and points can produce duplicate entries if not handled properly.

2. Data Handling Under Concurrency

Use table design with unique constraints, transactions, and server‑side locks to guarantee data consistency. Both massive legitimate traffic and malicious request bursts must be considered.

Example 1 – Sign‑in with Unique Constraint

Requirement: each user can sign in once per day and receive points.

Design: create a sign‑in record table with a unique index on (user_id, date). Insert the sign‑in record then add points within a single SQL transaction.

Example 2 – Lottery with Transaction and Update Lock

Requirement: lottery consumes a point and decrements prize stock; cannot proceed when stock or points are zero.

Design: wrap the operation in a transaction and use WITH (UPDLOCK) or an UPDATE lock on the prize table, then deduct points.

Example 3 – Cache Update with Lock (C#)

Requirement: cache data in Redis; if missing, fetch from DB and store; cache refreshed at 10 am and every two hours otherwise.

Solution: surround the DB‑to‑cache code with a C# lock to ensure only one request hits the database under high load.

3. High‑Concurrency Architecture

Key components include load‑balancing (e.g., Nginx, SLB), clustered databases (MySQL master‑slave, NoSQL clusters), Redis caching, CDN for static assets, and monitoring.

Load balancer distributes traffic across multiple servers.

Database clusters and read‑write separation reduce pressure.

Redis/MongoDB/Memcached provide fast data access.

Static files served via CDN.

Typical Workflow for User Sign‑in

Check Redis hash for today’s sign‑in record.

If not found, query DB; if DB has a record, sync it to Redis.

If still missing, insert sign‑in record and points inside a transaction.

Cache the new record in Redis.

Message Queue for Spike Events

For activities like flash‑sale or timed red‑packet distribution, push user actions into a Redis list or other queue, then consume with multithreaded workers to avoid DB overload.

First‑Level Cache

Store hot data in the web server’s memory with a short TTL to reduce connections to the external cache during peaks.

Static Data Strategy

Export rarely changing data to JSON/HTML files, upload them to a CDN, and let clients fetch from the CDN unless a newer version is required.

4. Concurrency Testing Tools

Apache JMeter

Microsoft Web Application Stress Tool

Visual Studio Load Test

Use these tools to simulate traffic, measure throughput, and validate that the architecture can sustain the expected load.