Capacity‑Driven Microservice Architecture: Solving High‑Concurrency Challenges

In high‑concurrency scenarios such as Double‑11 shopping, train‑ticket rushes, and live‑event streaming, system stability becomes a key quality metric. Traditional domain‑driven microservice decomposition often hides capacity bottlenecks, causing service avalanches when a core domain experiences traffic surges.

Core positioning : the architecture treats capacity indicators (QPS, TPS, RT) as the "baton" for service splitting, ensuring each service’s capacity boundary is visible and independently scalable.

Three design ideas :

Capacity‑driven module split – modules are divided according to the peak traffic and resource limits of core services, separating read/write, core/non‑core flows via front‑proxy instances to avoid interference.

Interface‑implementation binding – each business sub‑domain defines an api contract and a matching impl that implements the logic, achieving low coupling while preserving high cohesion.

Domain‑rule cohesion – business rules are isolated from technical adapters (e.g., MQ, scheduled jobs), clarifying boundaries between pure domain logic and infrastructure concerns.

Four module responsibilities :

Aggregation application (proxy) : acts as the traffic entry point and orchestrator, routing core‑transaction, high‑frequency query, and client‑side traffic to dedicated proxy instances; it is stateless and can be dynamically scaled.

Domain rules : the business "core engine" containing sub‑domain APIs, common utilities, and core components that implement pure business logic without dependence on aggregation or application layers.

Domain applications : independently deployable execution units that host sub‑domain implementations, scheduled jobs, and MQ consumers, enabling isolated scaling and fault isolation.

Basic components : provide shared technical capabilities such as BOM management, bean injection, core utilities, and RPC communication, serving as a common foundation for all modules.

The architecture’s practical value lies in its ability to make capacity boundaries explicit, prevent "one‑node‑failure‑all‑down" scenarios, balance decoupling with coordinated execution, and accelerate development by separating business rules from technical adapters. For e‑commerce, travel, and live‑streaming platforms that regularly face traffic peaks, this capacity‑driven approach is presented as a mandatory rather than optional solution.