Database Replication Strategies
To achieve scalability in a high-load system, the Database needs to be replicated.
Below are two famous replication strategies:
- Master-Slave
- Master-Master
After discussing these two, let's discuss a real-world database replication strategy for highly scalable systems.
Master-Slave Database Replication
Read/Write request is handled by master but slave handles only Read requests.
There are two ways to write to Slave:
Async
Write is considered successful when data is written to master. Slave is updated asynchronously in the background.
Advantages: Faster writes.
Trade-Offs: Gives eventual consistency. Possibility of data loss in case of master goes down before changes are written to slave.
Sync
Write is considered successful when data is written to both master and slave.
Advantages: No data loss.
Trade-offs: The system will be highly consistent but not highly available (read CAP theorem for more details). If slave goes down, write won't succeed even if master is alive.
Master-Master Database Replication
Data can be written to either of the master and masters can sync the data asynchronously.
Advantages: Highly available system.
Problems: Write conflict.
A more practical approach for highly scalable systems
A combination of all the above strategies will make the system more robust. Let's discuss the approach now.
To avoid data loss while keeping low latency in the Master-Slave replication strategy, sync strategy is used to create a (warm) backup of Master. Thus, a write is considered successful when data is written to Master and Master-backup.
Master-Master replication is generally used for multi-geography services. Eg Uber booking. One user won't book a cab in Delhi and New York simultaneously.
Ever heard of a Peer-to-Peer strategy or a strategy where all nodes are treated equally? No? Then this article is for you. :)
Feel free to leave comments and don’t forget to clap if you liked the content.
