How to Evolve High‑Traffic Data Architecture: From Simple Reads to Decentralized Caching

Background

In internet scenarios, product traffic often grows from low to massive scale. The original architecture may become unreasonable, hindering stability. The issue is not necessarily a lack of architectural skill, but over‑estimating capacity and redundancy in low‑traffic phases, wasting resources and manpower. Instead, we should prepare for scalability and enable tiered degradation of data‑store dependencies.

Strong Dependency Degradation Process

Stage 1: Simple traffic, no read‑write separation

When a service is newly launched with minimal traffic, it usually runs a single database instance handling both reads and writes, as shown below:

Advantages:

High resource utilization under low traffic.

Strong consistency, no read‑write ordering issues.

Disadvantages:

Read and write interfere; a failure makes the whole service unavailable.

Stage 2: Traffic rises, reads dominate, read‑write separation

Large‑scale systems typically separate reads and writes when traffic reaches a certain size and the read/write ratio is at least 8:2. The architecture looks like:

Read‑write separation distributes read operations to multiple replica servers while a master handles writes, improving concurrency and overall performance. The master synchronizes changes to replicas to maintain consistency.

Benefits include load balancing and automatic failover. Challenges involve replication lag and added complexity for consistency and recovery.

Stage 3: Multi‑region traffic and high stability – “two‑site three‑center”

The “two‑site three‑center” model builds three centers: a local production center, a same‑city disaster‑recovery center, and an off‑site disaster‑recovery center, ensuring high availability and data safety even during large‑scale traffic or disasters.

Core metrics show improved availability, keeping the system robust under massive load.

Stage 4: Cache‑based risk mitigation

Caching acts as a safety net, preventing total outage when the persistent data layer fails, while also boosting performance. A cache layer adds a protective layer, dramatically increasing availability.

Stage 5: Decentralized local cache to further boost availability

Placing data as close to users as possible reduces latency and risk. Decentralization ensures services remain usable even when all dependencies fail. The approach keeps a local copy of critical data with acceptable delay (e.g., up to four hours) so the service stays up.

Conclusion

The article outlines the evolution of high‑traffic data dependency degradation in internet scenarios. Key points:

Read‑write separation enables recovery from single‑point storage failures.

Two‑site three‑center architecture raises availability against regional risks.

Caching improves performance and provides fallback for data‑center failures.

Local cache achieves decentralization, keeping services independent even when dependencies fail.