Analyzing the Write‑After‑Read Consistency Challenge in Multi‑Active Distributed Architectures

The article builds on a previous discussion of multi‑active (cross‑region) disaster‑recovery architecture and focuses on the "write‑after‑read" (WAR) problem, where a read request arriving shortly after a write must return the most recent value.

Three fundamental approaches to guarantee WAR are presented: (1) single‑write‑single‑read routing, ensuring the read always goes to the unique write node; (2) multi‑write‑multi‑read (NRW) where the number of write nodes (W) plus read nodes (R) exceeds the total node count (N), providing quorum‑based consistency; and (3) read‑while‑copy, where the read node checks whether it holds the latest data and, if not, waits for replication before responding.

The article explains why the NRW model is costly in cross‑city scenarios—each read may involve long‑distance round‑trips and the need to write to many nodes—so many systems prefer a primary‑secondary (master‑slave) replication model. In this model, writes are acknowledged after being replicated to a subset of slaves, and WAR requests are typically routed to the primary, effectively reducing to a single‑write‑single‑read case.

A concrete business case is described: a three‑region, five‑center architecture using half‑synchronous master‑slave replication, a name‑service that abstracts read/write endpoints, and the requirement to identify "hot" data that must be read from the primary to satisfy WAR. The case highlights three observations: (1) the replication mode only guarantees redundancy, not immediate consistency; (2) the name‑service provides both a write name (pointing to the primary) and a read name (pointing to any nearby replica); (3) for WAR, the read routing must select the write name.

Based on this analysis, a four‑step solution framework is proposed: (1) distinguish business scenarios to flag requests that need WAR; (2) mark written data either by attaching a write‑identifier to the client response or by recording recent writes in the backend; (3) evaluate latency requirements, considering cross‑city RTT (e.g., ~30 ms) and the criticality of reading the latest value; (4) provide near‑by access by asynchronously replicating the newly written data to local caches after the primary write, using lightweight CAS writes, short‑term reconciliation, and a unified API for services that need this capability.

The article concludes that WAR is a typical locality‑driven consistency issue. By leveraging detailed database‑level replication information together with business‑side scenario classification, data‑marking, latency assessment, and near‑by replication, the problem can be solved efficiently without imposing heavyweight distributed consensus across all nodes.