Replication
In this chapter, we keep copies of Shopend’s database on several servers, so that reads can be spread across them and another server can take over when one fails.
After reading this chapter, you should be able to:
- Explain why more API instances, indexes, caching, or a larger server may not relieve a database bottleneck
- Define replication and replica, and explain why replicas must be kept up to date
- Explain how two replicas that both accept writes can oversell a product
- Define single-leader replication, and explain why conditional updates and transactions are still needed
- Decide which reads can go to a replica and which must stay on the primary
- Define replication lag and read-your-writes, and compare two ways to provide read-your-writes
- Define failover and explain how the replacement primary is chosen
- Distinguish asynchronous and synchronous replication, and choose when to confirm a write
- Choose between a cache and a replica for a read, and explain why replicas do not spread the writes