Database Replication

Replication is about Availability and **Read Scalability**. By keeping copies of your data on multiple servers, you can survive the death of a database node and handle millions of read requests.

1. Master-Slave (Leader-Follower)

One "Master" node receives all writes. It then broadcasts the changes to multiple "Slave" nodes. All reads are performed against the slaves. Best for: Read-heavy apps (Social Media, Blogs).

2. Multi-Master (Leader-Leader)

Every node can receive both reads and writes. Nodes eventually sync with each other. Pros: No single point of failure for writes. Cons: "Conflict Resolution" is a nightmare. If two people update the same record on different masters at the same time, which one wins?

4. Interview Mastery

Q: "What is 'Replication Lag' and how do you handle it?"

Architect Answer: "Replication lag is the delay between a write finishing on the Master and appearing on the Slave. If a user updates their profile and then immediately refreshes, they might see the 'Old' data from the slave. We fix this using **Read-Your-Own-Writes** consistency: we force any reads that occur within X seconds of a write to go directly to the Master instead of the slaves."