Data replication strategies in HLD - System Design Exercise

Design: Data Replication System

Design focuses on replication strategies and architecture for database systems. Does not cover detailed database schema design or application-level logic.

Functional Requirements

FR1: Replicate data across multiple database nodes to improve availability and fault tolerance

FR2: Support both synchronous and asynchronous replication modes

FR3: Ensure data consistency according to the chosen replication strategy

FR4: Allow read scaling by directing read requests to replicas

FR5: Handle failover automatically in case of primary node failure

FR6: Support recovery and catch-up of lagging replicas

Non-Functional Requirements

NFR1: System must support up to 1000 write transactions per second

NFR2: Replication latency should be under 100ms for synchronous mode

NFR3: Availability target of 99.9% uptime

NFR4: System should tolerate network partitions and node failures gracefully

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Primary (master) database node

Replica (slave) database nodes

Replication log or write-ahead log (WAL)

Replication coordinator or manager

Failover detection and leader election mechanism

Monitoring and alerting system

Design Patterns

Master-slave replication

Multi-master replication

Synchronous vs asynchronous replication

Quorum-based replication

Log shipping and streaming replication

Conflict resolution strategies

Reference Architecture

          +---------------------+
          |     Application     |
          +----------+----------+
                     |
                     v
          +---------------------+          +---------------------+
          |   Primary Database   |<-------->| Replication Manager  |
          +----------+----------+          +----------+----------+
                     |                               |
        (Write-Ahead Log/WAL)                        |
                     |                               |
          +----------v----------+          +---------v----------+
          |   Replica Database   |          |   Replica Database  |
          +---------------------+          +---------------------+

Components

Primary Database

Relational or NoSQL DB with WAL support

Handles all write operations and generates replication logs

Replica Database

Same as primary

Receives and applies replication logs to stay in sync for reads and failover

Replication Manager

Custom or built-in DB component

Coordinates replication, manages log shipping, monitors lag and health

Failover Mechanism

Leader election tools like ZooKeeper or Raft

Detects primary failure and promotes a replica to primary

Request Flow

1. 1. Application sends write request to Primary Database.

2. 2. Primary writes data and records changes in Write-Ahead Log (WAL).

3. 3. Replication Manager streams WAL entries to Replica Databases.

4. 4. Replica Databases apply changes from WAL to update their data.

5. 5. Application read requests can be served from Replica Databases to reduce load on Primary.

6. 6. Failover Mechanism monitors Primary health; if failure detected, promotes a Replica to Primary.

7. 7. Lagging replicas catch up by replaying missing WAL entries.

Database Schema

Entities: None specific to replication; replication uses database transaction logs (WAL). Relationships: Primary node streams WAL to multiple Replica nodes in 1:N fashion.

Scaling Discussion

Bottlenecks

Primary node write throughput limits overall system writes

Network bandwidth limits replication log shipping speed

Replication lag increases with distance and load

Failover detection delay can increase downtime

Conflict resolution complexity in multi-master setups

Solutions

Scale primary vertically or shard data to distribute writes

Use compression and efficient protocols for log shipping

Deploy replicas closer to clients for read scaling and reduce lag

Implement fast leader election algorithms and health checks

Use conflict-free data types or application-level conflict resolution in multi-master

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain trade-offs between synchronous and asynchronous replication

Discuss consistency vs availability considerations

Describe how replication logs (WAL) enable data synchronization

Highlight failover and recovery mechanisms

Mention scaling challenges and solutions

Use simple diagrams to illustrate data flow

Practice

1. Which data replication strategy ensures that all copies of data are updated at the same time before confirming a write operation?

easy

A. Synchronous replication

B. Asynchronous replication

C. Master-slave replication

D. Multi-master replication

Solution

1. Step 1: Understand synchronous replication

   Synchronous replication waits for all copies to confirm the write before completing the operation.

2. Step 2: Compare with other strategies

   Asynchronous replication does not wait, master-slave and multi-master describe topology, not timing.

3. Final Answer:

   Synchronous replication -> Option A

4. Quick Check:

   Strong consistency = Synchronous replication [OK]

Hint: Strong consistency means waiting for all copies to update [OK]

Common Mistakes:

• Confusing asynchronous with synchronous replication
• Mixing replication timing with replication topology
• Assuming master-slave means synchronous

2. Which of the following is the correct description of asynchronous replication?

easy

A. Replicas confirm the data before the primary confirms the write

B. Data is copied to replicas without waiting for confirmation from them

C. Data is copied simultaneously to all replicas with confirmation

D. Data is copied to replicas before the primary confirms the write

Solution

1. Step 1: Define asynchronous replication

   It copies data to replicas but does not wait for their confirmation before confirming the write.

2. Step 2: Eliminate other options

   Replicas confirm the data before the primary confirms the write requires replica confirmation before primary ack (synchronous); B copies before primary ack (incorrect); C describes synchronous behavior.

3. Final Answer:

   Data is copied to replicas without waiting for confirmation from them -> Option B

4. Quick Check:

   Asynchronous = no wait for replica confirmation [OK]

Hint: Asynchronous means no waiting for replicas to confirm [OK]

Common Mistakes:

• Thinking asynchronous waits for replicas
• Confusing timing of data copy
• Mixing synchronous and asynchronous definitions

3. Consider a system using master-slave replication. If the master receives a write request, what happens next?

medium

A. The write is applied simultaneously to master and slaves synchronously

B. The write is applied to all slaves first, then to the master

C. The write is only applied to slaves, not the master

D. The write is applied to the master and then asynchronously copied to slaves

Solution

1. Step 1: Understand master-slave replication flow

   Writes go to the master first, then are copied to slaves, usually asynchronously.

2. Step 2: Check other options

   Slaves do not receive writes first or alone; synchronous writes to all are not typical in master-slave.

3. Final Answer:

   The write is applied to the master and then asynchronously copied to slaves -> Option D

4. Quick Check:

   Master handles writes first in master-slave [OK]

Hint: Master handles writes first, slaves get updates later [OK]

Common Mistakes:

• Assuming slaves can accept writes first
• Confusing synchronous with asynchronous replication
• Thinking slaves are independent masters

4. A system using multi-master replication faces conflicts when two masters update the same data simultaneously. What is a common way to fix this issue?

medium

A. Switch to asynchronous replication only

B. Disable writes on all but one master

C. Use conflict resolution strategies like timestamps or version vectors

D. Remove all replicas and use a single database

Solution

1. Step 1: Identify conflict in multi-master replication

   Simultaneous writes cause conflicts that need resolution strategies.

2. Step 2: Evaluate conflict resolution methods

   Timestamps or version vectors help decide which write wins or how to merge.

3. Final Answer:

   Use conflict resolution strategies like timestamps or version vectors -> Option C

4. Quick Check:

   Conflict resolution = timestamps/version vectors [OK]

Hint: Resolve conflicts with timestamps or version vectors [OK]

Common Mistakes:

• Disabling multi-master writes defeats purpose
• Thinking asynchronous replication solves conflicts
• Removing replicas is impractical

5. You are designing a global application with users worldwide needing fast reads and writes. Which replication strategy best fits this use case?

hard

A. Multi-master replication with conflict resolution

B. Master-slave replication with synchronous writes

C. Single master with asynchronous replication

D. No replication, single database instance

Solution

1. Step 1: Analyze global user needs

   Users worldwide require fast reads and writes from multiple locations.

2. Step 2: Match replication strategy

   Multi-master allows writes at multiple locations with conflict resolution, improving speed and availability.

3. Step 3: Eliminate other options

   Master-slave with synchronous writes is slow globally; single master limits write locations; no replication is slow and risky.

4. Final Answer:

   Multi-master replication with conflict resolution -> Option A

5. Quick Check:

   Global fast writes = multi-master + conflict resolution [OK]

Hint: Global writes need multi-master with conflict handling [OK]

Common Mistakes:

• Choosing synchronous master-slave for global writes
• Ignoring conflict resolution in multi-master
• Using single master limits write speed globally