distributed-data • Intermediate

Database Replication: Read Replicas, Replication Lag & Split-Brain

Primary-Replica database topologies scale read throughput by offloading queries to asynchronous read replicas. Replication lag introduces read-your-own-writes inconsistencies, requiring sticky sessions or primary reads.

Intuitive Mental Model

The Photocopy Bulletin Board: The manager writes a new schedule on the master board (Primary). Assistants photocopy it for the hallways (Replicas). If an employee walks into the hallway 3 seconds later, the photocopy may still show yesterday's schedule.

Architecture Blueprint & CodeProduction Standard

// Read-Your-Own-Writes Pattern:
async function getUserProfile(userId: string) {
  const lastWriteTime = await redis.get(`user:${userId}:last_write`);
  if (lastWriteTime && Date.now() - Number(lastWriteTime) < 5000) {
    // Write occurred recently; route read to Primary DB to avoid replication lag!
    return primaryDB.query('SELECT * FROM users WHERE id = ?', [userId]);
  }
  return replicaDB.query('SELECT * FROM users WHERE id = ?', [userId]);
}

Key Architectural Takeaways

•Asynchronous Replication: High write performance, but replicas can fall behind by hundreds of milliseconds.
•Semi-Synchronous Replication: Primary waits for at least 1 replica to acknowledge before returning success to client.

Common Architectural Pitfall

Reading from a read replica immediately after a user profile update, displaying stale old data to the user.

Production Best Practice

Route reads to Primary DB for 5 seconds after a user write (Read-Your-Own-Writes consistency).

Next: Distributed Transactions: 2-Phase Commit (2PC) vs Saga Pattern