Core Module
12 min forge

Database Replication

Master high availability for your data. Learn how to keep multiple copies of your database synchronized across servers.

πŸ‘― Database Replication: Safety in Numbers

Replication is the process of sharing information so as to ensure consistency between redundant resources, such as software or hardware components, to improve reliability, fault-tolerance, or accessibility.

πŸ’‘ The Logic (ELI5)

Think of a Backup Band:

  1. You have a Lead Singer (The Master/Primary).
  2. You also have 3 Backup Singers (The Replicas/Secondaries).
  3. The Lead Singer wears a microphone and sings the original song (Handles all Writes).
  4. The Backup Singers listen to the Lead and repeat exactly what they hear (Sync from Master).
  5. If someone in the back of the room can't hear the Lead, they can listen to a Backup Singer (Handles Reads).
  6. If the Lead Singer loses their voice, one of the Backups steps up and becomes the new Lead!

πŸ” The Deep Dive

Why Replicate?

  1. High Availability: If the primary server crashes, a replica can take over (Failover).
  2. Read Scalability: You can add many replicas to handle millions of read requests (e.g., social media feeds).
  3. Data Localization: Keep a copy of the database physically close to users in different countries.

Replication Models

  • Master-Slave (Primary-Secondary): All writes go to the Master; Master syncs data to Slaves; Slaves handle all reads.
  • Master-Master (Multi-Primary): Both servers can handle writes. Very complex because of "Write Conflicts."
  • Quorum (Peer-to-Peer): Any node can handle any request. Nodes vote to decide which data is the "truth" (e.g., Cassandra).

🎯 Interview Pulse

Use Case: Read-Heavy vs. Write-Heavy

Replication is a Read-Scaling solution. It doesn't help with write-heavy systems (like a stocks tracker) because every write still has to hit the master. For write-heavy systems, you need Sharding.

Synchronous vs. Asynchronous Sync

  • Synchronous: The master waits for the replica to confirm it saved the data before telling the user "Success." Very safe, but very slow.
  • Asynchronous: The master saves data and tells the user "Success" immediately, then syncs to replicas in the background. Faster, but leads to "Eventual Consistency" (a user might read old data for a few seconds).

Top Tip

Whenever you design a system for "99.99% Availability," always mention Replication. No single server is 100% reliable; you must have a copy. πŸ‘―