Mastering High‑Performance, High‑Concurrency Backend Systems: Methodologies & Practices

High Performance

The core of a "three‑high" system (high performance, high concurrency, high availability) lies in performance; fast processing and high throughput enable the system to handle massive traffic, reduce latency, and improve availability. The performance chapter discusses read/write optimization methods.

Methodology

System performance is affected by computation, communication, and storage. Issues include complex business logic, full GC, slow downstream services, large tables, slow SQL, and mis‑configured Elasticsearch shards. Optimizations are approached from read and write dimensions.

Read Optimization: Cache and Database Integration

Cache (local or distributed) is the most effective way to boost performance. Typically, cache is combined with the database: read‑heavy systems use synchronous DB updates and delete cache afterwards, while write‑heavy systems update cache synchronously and the database asynchronously. The dominant data source (DB or cache) depends on the read/write pattern.

Write Optimization: Asynchronous Processing for Flash‑Sale Scenarios

In peak‑traffic flash‑sale cases, order‑taking interfaces avoid heavy synchronous logic. Orders are accepted asynchronously, a message queue smooths the spike, inventory is cached, and users are notified after successful stock deduction.

High Concurrency

Improving concurrency involves both single‑machine performance tuning and cluster‑level scaling (horizontal, vertical, and Z‑axis expansion). Horizontal scaling adds machines and shards; vertical scaling refactors monoliths into microservices using DDD; Z‑axis scaling adds database replicas and shards to avoid bottlenecks.

Horizontal Scaling

Vertical Scaling

The architecture evolved from monolith to SOA, microservices, and service mesh. Domain‑Driven Design (DDD) guides service boundaries, as illustrated by an e‑commerce example.

Z‑Axis Scaling (Sharding & Replication)

Adding machines increases DB connections; when connections hit limits, storage becomes the bottleneck. Sharding (database partitioning) and replication (master‑slave) increase connection capacity. Unit‑based deployment distributes traffic and data across geographic regions, reducing latency and improving availability.

DDD Practice in Retail Logistics Platform

Business processes are mapped to domains: product service, order, payment, and fulfillment. The workflow includes forward (B‑side order creation, service provider acceptance, delivery) and reverse (C‑side return) processes, illustrated with diagrams.

Hot‑Key Handling

Hot keys cause traffic skew; solutions include local cache hierarchy and adding random suffixes to keys to distribute load across shards.

High Availability

Ensuring availability relies on protection and redundancy. The article covers application‑level, storage‑level, and deployment‑level strategies.

Application Layer

Key techniques: rate limiting (counter, sliding window, leaky bucket, token bucket), circuit breaking, timeout settings (following the funnel principle), retries with idempotency, isolation (system, environment, data, core/non‑core, read/write, thread‑pool), and compatibility (forward and backward).

Storage Layer

High availability achieved through replication (master‑slave, multi‑master, leaderless) and partitioning (range and hash). Redis cluster uses 16384 slots with master‑slave replication; Elasticsearch indexes have primary and replica shards; Kafka topics are partitioned with leader/follower replicas.

Deployment Layer

Evolution from single‑machine to multi‑data‑center, multi‑region deployments using redundancy and load balancing. Current setup uses Docker containers across multiple rooms, dual‑room MySQL, Redis, and single‑room Elasticsearch, with traffic isolation per business importance.