Data Replication
Every production database uses replication. Without it, a single server failure means data loss and downtime.
Quick answer: Data Replication
Data Replication is covered here as a practical system design concept. Every production database uses replication. Without it, a single server failure means data loss and downtime. Use it to understand the Databases idea, where it appears in production systems, and how to discuss it clearly in interviews.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
When You Need Data Replication
Every production database uses replication. Without it, a single server failure means data loss and downtime. In interviews, you must explain how replication affects consistency, availability, and performance.
What It Is
Data replication is the process of copying data from one database server (primary/master) to one or more other servers (replicas/slaves). It provides redundancy (survive server failures), performance (distribute reads across replicas), and geographic distribution (replicas near users).
How It Works
In leader-follower replication: All writes go to the leader. The leader writes to its write-ahead log (WAL). The WAL is streamed to followers, which replay the changes. Reads can go to any follower. If the leader fails, a follower is promoted (failover).
Replication lag is the delay between a write on the leader and that write being visible on a follower. During lag, reading from a follower may return stale data.
The Decision Framework
- Synchronous replication: The primary waits for replicas to confirm before committing. Guarantees consistency but adds latency.
- Asynchronous replication: The primary commits immediately and sends changes to replicas in the background. Fast but replicas may lag (eventual consistency).
- Semi-synchronous: The primary waits for at least one replica to confirm. Balances consistency and performance.
- Leader-follower (primary-replica): One leader handles writes; followers handle reads. Most common pattern.
- Multi-leader: Multiple nodes accept writes. Used for multi-region deployments. Requires conflict resolution.
- Leaderless (quorum): Any node can accept reads/writes. Uses quorum (R + W > N) for consistency. Used by Dynamo, Cassandra.
What the Industry Uses
PostgreSQL streams WAL records to replicas for leader-follower replication. Hot standby replicas serve read queries.
MySQL offers both asynchronous and semi-synchronous replication. Group Replication provides multi-leader with conflict detection.
Amazon Aurora replicates data 6 times across 3 availability zones with <20ms replication lag.
Performance and Tradeoffs
- Sync vs Async: Sync guarantees consistency but adds write latency. Async is faster but allows stale reads.
- Single-leader vs Multi-leader: Single-leader is simpler; multi-leader enables multi-region writes but requires conflict resolution.
- Read replicas vs Sharding: Replicas scale reads; sharding scales both reads and writes. Use both for maximum scale.
Mistakes Engineers Make
- Reading from a replica immediately after writing — may return stale data (read-after-write consistency issue)
- Not monitoring replication lag — a lagging replica can serve very stale data
- Using synchronous replication across regions — adds 100ms+ latency per write
Practice These Interview Questions
- What are the types of replication strategies?
- What is replication lag and how does it affect the system?
- When would you use synchronous vs asynchronous replication?
- How does quorum-based replication work?
Original DosiBridge notes for Data Replication
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Data Replication is to connect the concept to a data path where correctness, access pattern, and future migrations matter more than benchmark numbers. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Query Shape: For Data Replication, decide the query shape before choosing tools; otherwise the design looks clean but fails when data changes.
- Write Amplification: For Data Replication, decide the write amplification before choosing tools; otherwise the design looks clean but fails when replication changes.
- Replication Lag: For Data Replication, decide the replication lag before choosing tools; otherwise the design looks clean but fails when data changes.
- Migration Safety: For Data Replication, decide the migration safety before choosing tools; otherwise the design looks clean but fails when replication changes.
- Data Ownership: For Data Replication, decide the data ownership before choosing tools; otherwise the design looks clean but fails when data changes.
Distinct angle: replication lag as a product behavior
Data replication is not only a storage feature. It changes what users see after a write, what support teams debug, and how failover behaves. A useful design names the acceptable lag per workflow: account balance may require synchronous confirmation, while analytics dashboards can tolerate delayed replicas. That makes replication a product promise instead of a vendor checkbox.
Production review question
If a team adopts Data Replication, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track data-replication health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Data Replication, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.
Further Reading
