Mastering High-Concurrency: Proven Read/Write Strategies for Scalable Systems

High concurrency problems can be divided into two categories: read‑heavy and write‑heavy.

Read‑heavy: e.g., e‑commerce product detail pages where view requests far exceed publish/modify.

Write‑heavy: e.g., ad billing systems where charging operations are massive.

Thus, strategies can be organized around “read” and “write”.

1. High‑Concurrency Reads

Strategy 1: Add Cache

Example 1: Local or centralized cache

Caching protects the database and improves read performance; it can be local or a centralized memcached/Redis cache.

Cache update methods:

Active update – update cache when database records change.

Passive update – refresh cache when a read finds it expired.

Three cache pitfalls to watch:

Cache avalanche – if the cache fails, the database may be overwhelmed.

Cache penetration – many missing keys cause direct DB hits.

Hot‑key expiration – many hot keys expire simultaneously, flooding the DB.

These issues relate to cache‑back‑origin strategies:

No back‑origin – only query cache; if missing, return empty (active update, no TTL).

Back‑origin – query DB and update cache when cache miss occurs.

Example 2: MySQL master‑slave

Deploy DB in master‑slave mode with read‑write separation; slaves act as caches for reads.

Example 3: CDN static file acceleration

Static assets (HTML, CSS, JS, images) are cached at CDN nodes worldwide, serving users from the nearest node.

Strategy 2: Concurrent Reads

Example: Asynchronous RPC

Calling three RPCs with latencies t1, t2, t3:

Synchronous total time = t1 + t2 + t3. Asynchronous total time = max(t1, t2, t3). Parallelism is viable when calls are independent.

Strategy 3: Rewrite Light Reads

Write extra redundant data to reduce read load.

Example 1: Social feed

Each user has an inbox; when a user posts, the message is asynchronously pushed to followers' inboxes, allowing reads to fetch pre‑assembled inboxes.

Example 2: Wide table

Pre‑compute joined data into a wide table or Elasticsearch documents for fast reads.

2. High‑Concurrency Writes

Strategy 1: Data Sharding

Example 1: Database sharding (split tables)

Sharding distributes write load across multiple instances.

Example 2: Java ConcurrentHashMap

Internally segmented into buckets, allowing concurrent reads/writes without contention.

Example 3: Kafka partitions

Each partition is independent, enabling concurrent read/write.

Example 4: Elasticsearch distributed index

Large indexes are split into smaller shards for parallel querying.

Strategy 2: Asynchronous

Example 1: SMS verification

Send SMS requests to a message queue and return immediately; workers process the queue.

Example 2: E‑commerce order splitting

One order request is split into multiple sub‑orders asynchronously.

Example 3: Ad billing

Clicks are queued and processed later, enabling batch charging.

Strategy 3: Batch

Example 1: Kafka massive writes

Partitions and batch sending improve throughput.

Example 2: Ad billing batch deduction

Combine multiple clicks into a single deduction to reduce DB writes.

Strategy 4: Serialize + Multi‑process single‑thread + Async I/O

Single‑threaded models like NGINX and Redis use async I/O to avoid lock contention; multiple instances provide multi‑core utilization.

Conclusion

Content compiled from “Software Architecture Design: Large‑Scale Website Architecture and Business Integration”.