How to Ensure Immediate Reads After Writes in Multi-Active Architectures

Problem Definition

The "write‑after‑immediate‑read" scenario requires that a read request arriving shortly after a write must return the value just written. This consistency requirement is common in Internet applications and becomes difficult in multi‑active, cross‑city disaster‑recovery architectures where replication latency can cause stale reads.

Typical Architecture Example

A three‑city, five‑center disaster‑recovery setup is used as a concrete example:

Primary‑secondary replication operates in semi‑synchronous mode: the primary commit succeeds after receiving acknowledgments from two replicas, but the specific replicas are not fixed.

A name‑service layer abstracts read/write routing, exposing a "write name" (points to the primary) and a "read name" (points to the nearest replica).

For immediate reads the routing must select the write name (the primary) to guarantee the freshest data.

Solution Directions

Single‑write single‑read : Route all immediate‑read requests to the unique write node (the primary). This guarantees that the read sees the latest write.

Multiple‑write multiple‑read (NRW) : Ensure the sum of write nodes (W) and read nodes (R) exceeds the total node count (N), i.e., N < R + W. This increases the probability of hitting a fresh replica but incurs higher cross‑city traffic and load.

Read‑time copy : When a read node receives a request, it checks whether its local copy is up‑to‑date; if not, it copies the latest data from the primary before responding.

Solution Model

Write source : Distinguish between user‑initiated fine‑grained writes and backend‑initiated bulk writes, as they impose different pressures on the primary.

Architecture impact : In a primary‑N‑secondary setup, a read that hits a secondary before replication completes may return stale data.

Timeliness analysis : Compare the write‑to‑read interval (how soon the read arrives) with the write‑to‑replication delay. If replication delay > read interval, stale reads occur.

Reader type : End‑users often need immediate consistency; backend processes can tolerate eventual consistency.

Scenario scope : Only a small subset of use‑cases require immediate reads. Identify those critical paths.

Data scope : Typically a limited set of data items (e.g., user‑triggered updates) are subject to the immediate‑read requirement.

Distinguish Business Scenarios

Caller‑side flag: The client includes a protocol field indicating an immediate‑read requirement.

Provider‑side identifier: The service assigns identifiers to callers and internally marks those that need immediate reads. This approach offers better control and is generally preferred.

Identify Written Data

For user‑triggered writes, return a write identifier (e.g., a version or transaction ID) in the response; the client can supply this identifier on subsequent reads.

Backend can maintain a recent‑write metadata store (e.g., a lightweight table or cache) that records the latest write timestamp or identifier for each key. Reads consult this store to decide whether the local replica is fresh.

Recording metadata adds complexity and introduces a reliability trade‑off compared with relying solely on the database replication state.

Assess Latency Requirements

Determine whether a cross‑city round‑trip latency (≈30 ms) is acceptable for the immediate‑read use case.

Identify how many data items are involved and whether each requires immediate consistency.

Decide if reads can be parallelized or must be sequential due to business logic dependencies.

Consider current and projected workload patterns to ensure the chosen solution remains viable.

Provide Near‑Access Capability

After the primary write succeeds, return the response to the client while concurrently writing copies to nearby replicas.

Use lightweight compare‑and‑swap (CAS) writes for the near replicas; on failure, retry a limited number of times.

Run short‑term asynchronous reconciliation to detect and correct divergence between the primary and near replicas, limiting the window of inconsistency.

Expose a simple API (e.g., /writeWithNearCopy) for services that need this capability, reducing integration effort.

Solution Summary

By leveraging detailed knowledge of database replication and focusing on the locality of the "write‑after‑immediate‑read" problem, a four‑step approach—distinguish scenarios, mark written data, evaluate latency, and enable near access—provides a practical path to achieve consistent, low‑latency reads without imposing a heavyweight global consistency model.