Structuring a High-Concurrency System Design Paper for the 2026 Soft Exam

Although the exam topic is considered difficult, the author argues that "High‑Concurrency System Design" is the easiest among the options because cloud‑native microservices, distributed architecture, Redis caching, message queues, and containerized deployment provide concrete ways to address high concurrency.

The recommended writing logic follows a fixed backbone: introduce the project background, identify performance challenges, discuss technical solutions, describe the actual problem and its resolution, and finally provide a summary and reflection. This structure is reusable for any architecture‑related paper.

The overview section should detail the project (e.g., an integrated e‑commerce platform with product sales, modules, payment settlement, coupons) and pinpoint the sources of high concurrency such as flash‑sales, large promotions, and coupons, which can cause traffic spikes up to 20× normal levels, data‑consistency issues, and multi‑tenant resource isolation.

Solution 1: Multi‑level cache design – combine CDN edge cache, Caffeine local cache, and a three‑tier Redis cluster. Include Bloom‑filter protection, TTL jitter, mutex locks, and logical expiration to prevent cache stampede, especially for flash‑sale scenarios using Redis DECR atomic operations to avoid overselling.

Solution 2: Asynchronous processing with message queue – decouple the synchronous path, handle time‑consuming operations asynchronously, and use RocketMQ to receive flash‑sale events, creating orders, persisting inventory, and issuing points later. Transactional messages guarantee eventual consistency between local transactions and message delivery.

Solution 3: Rate limiting and degradation – implement gateway‑level token‑bucket limiting with Sentinel, service‑level multi‑dimensional limiting, and a three‑level fallback: disable non‑core functions, fall back to cached data, and retain only the core payment flow.

Solution 4: Database optimization – reduce DB pressure with caching, apply read‑write separation, master‑slave replication, and sharding (e.g., hash‑sharding by user ID) to improve query efficiency.

Solution 5: Microservice decomposition – based on DDD, split the system into independent services such as product, inventory, order, payment, user, venue, points, and coupons, ensuring that flash‑sale load does not affect other services.

Solution 6: Horizontal scaling and elastic stretch – use Kubernetes HPA with a policy like CPU > 70% to trigger automatic scaling within 30 seconds, pre‑warm resources based on historical data, and validate capacity through stress testing.

When applying these solutions, bind each technique to a concrete issue; for example, flash‑sale oversell caused by direct MySQL writes is solved by Redis pre‑deduction plus MQ async smoothing. Quantitative results show QPS increasing from 2 000 to 16 000 and DB CPU dropping from 98 % to 35 %.

The final summary should close with quantitative metrics (response time, throughput, availability), extract lessons about multi‑dimensional coordination rather than single‑technology stacking, and suggest future improvements such as Service Mesh traffic governance and chaos‑engineering resilience.