Solving the Invisible Update Bug: Read-Your-Writes Guide

The Invisible Update: Understanding Read-Your-Writes Consistency

We have all been there. You update your profile settings, click "Save," and the page reloads. For a split second, everything looks correct—then, you hit refresh, and your changes vanish. The old data is back. You panic, re-type your changes, hit save again, and suddenly, your previous update reappears.

This is the classic "invisible update" bug. It is a textbook failure of read-your-writes consistency in distributed systems. While it may seem like a simple UI glitch, it is actually a profound architectural challenge that highlights the friction between database scalability and user experience.

What Is Happening Under the Hood?

In modern web applications, we rarely read and write from the same database instance. To achieve high availability and handle massive read traffic, we use a primary-replica architecture.

The primary database handles all write operations, while read replicas handle the heavy lifting of serving GET requests. The problem arises during the replication process:

1. The Write: Your application sends an UPDATE command to the primary database. It commits successfully.
2. The Replication: The primary database writes the change to its Write-Ahead Log (WAL) and asynchronously propagates that change to the read replicas.
3. The Read: Milliseconds after the write, the user’s browser triggers a GET request. Your load balancer, attempting to distribute traffic, routes this read to a replica that hasn't yet processed the WAL entry from the primary.

The replica returns the stale data. The user thinks their data is gone. Five seconds later, the replication catches up, and the data "magically" reappears. This is the definition of eventual consistency failing the user's expectation of immediate feedback.

The Anti-Pattern: The Lazy Hack

Early in my career, we tried to solve this with a "lazy hack": routing all reads to the primary database for 10 seconds after any write.

While this technically solves the consistency issue, it is a performance nightmare. By routing all post-write traffic to the primary, you negate the benefits of having read replicas. Under high load, this causes a stampede on the primary database, leading to increased latency and potential outages. It is fragile, unscalable, and ultimately, a band-aid on a systemic issue.

Three Robust Solutions for Modern Systems

If you want to maintain scale without sacrificing user trust, you need to implement more sophisticated strategies.

1. LSN-Based Routing (The Gold Standard)

The most reliable way to ensure consistency is to track the state of the database using a Log Sequence Number (LSN) or a Global Transaction ID (GTID).

Instead of guessing how long replication takes, we track the specific point in the transaction log where the user's write occurred.

The Workflow:

• When a write completes, the database returns the LSN of that transaction.
• Store this lastWriteLSN in a fast cache like Redis, scoped to the user session (e.g., user:123:last_lsn).
• When a read request arrives, the application queries the replica’s current LSN.
• If replicaLSN >= userLastWriteLSN, the replica is "up to date" and safe to read from.
• If not, the application routes the read to the primary.

// Conceptual logic for LSN-based routing
async function getConsistentRead(userId, query) {
  const userLastLSN = await redis.get(`user:${userId}:last_lsn`);
  const replicaLSN = await db.replica.execute('SELECT pg_last_wal_replay_lsn()');

  if (replicaLSN >= userLastLSN) {
    return db.replica.query(query);
  }

  // Fallback to primary for strict consistency
  return db.primary.query(query);
}

2. Define Strict 'Trust Boundaries'

Not every piece of data requires strong consistency. Applying the same strict routing logic to your entire application is overkill.

Instead, define "trust boundaries."

• High-Trust Data: Billing info, security settings, passwords, and account status. These should always be read from the primary database to ensure the user sees the absolute truth.
• Low-Trust Data: Activity feeds, non-critical dashboards, or public profiles. These are perfect candidates for eventual consistency.

By segregating your data, you reduce the load on the primary database while keeping the most critical user interactions consistent.

3. Leverage Optimistic UI

Sometimes, the best infrastructure fix is actually a client-side fix. Optimistic UI is a pattern where the frontend updates to reflect the user's action immediately, assuming the server request will succeed.

In frameworks like React or Next.js, instead of waiting for a full server re-fetch, you update your local state (e.g., React Query or SWR cache) as soon as the API returns a 200 OK. By bypassing the immediate read from the server, you avoid the replication lag issue entirely. If the request fails, you simply roll back the state and show an error message.

Conclusion: Balancing Consistency and Scale

System architecture is always a series of trade-offs. Forcing global strong consistency kills your ability to scale reads, but ignoring replication lag destroys user trust.

The key is to be intentional. Use Optimistic UI for immediate feedback, define Trust Boundaries to protect critical data, and implement LSN-based routing when you absolutely need to guarantee that a user sees their own writes.

How does your team handle database replication lag in production? Let's discuss in the comments.