Bird
Raised Fist0
HLDsystem_design~12 mins

Data replication strategies in HLD - Architecture Diagram

Choose your learning style10 modes available
System Overview - Data replication strategies

This system explains common data replication strategies used to improve data availability, fault tolerance, and read performance in distributed systems. It covers synchronous and asynchronous replication methods, showing how data is copied from a primary database to one or more replicas.

Architecture Diagram
User
  |
  v
Load Balancer
  |
  v
Primary Database (Master)
  |           \
  |            \---> Replica 1 (Slave)
  |            \
  |             \---> Replica 2 (Slave)
  |
  v
Cache
  |
  v
Application Server
Components
User
client
Initiates requests to the system
Load Balancer
load_balancer
Distributes incoming requests to the primary database or replicas
Primary Database (Master)
database
Main data store where writes happen and data is replicated from
Replica 1 (Slave)
database_replica
Read-only copy of primary database for load distribution and fault tolerance
Replica 2 (Slave)
database_replica
Additional read-only copy for scalability and availability
Cache
cache
Stores frequently accessed data to reduce database load and latency
Application Server
service
Processes business logic and serves responses to users
Request Flow - 8 Hops
User → Load Balancer
Load Balancer → Primary Database (Master)
Primary Database (Master) → Replica 1 (Slave)
Primary Database (Master) → Replica 2 (Slave)
Load Balancer → Replica 1 (Slave)
Replica 1 (Slave) → Cache
Cache → Application Server
Application Server → User
Failure Scenario
Component Fails:Primary Database (Master)
Impact:Writes fail and data replication stops; reads can continue from replicas but may be stale
Mitigation:Promote a replica to primary using failover mechanisms; use replication logs to catch up replicas
Architecture Quiz - 3 Questions
Test your understanding
Which component handles write requests in this replication strategy?
AReplica 1 (Slave)
BPrimary Database (Master)
CCache
DLoad Balancer
Design Principle
This architecture demonstrates how data replication improves system availability and read scalability by copying data from a primary database to multiple replicas. It balances consistency and performance using synchronous or asynchronous replication methods.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard