Stop Sending Every Request to One Database

Your application is growing, and one database server is becoming a bottleneck. Database replication keeps copies of the same database on several servers, so they can share the load without splitting your data. This video builds one cluster (an app, a primary and three replicas) and runs every idea through it. Each database shows the value it currently holds, so you can watch writes go to the primary, reads spread across the replicas, and changes travel between them. You can see the moment a replica falls behind. It covers primary-replica and multi-primary replication, write conflicts, synchronous vs asynchronous replication, replication lag and read-your-own-writes, and failover, including split brain and lost writes. Then it covers where replication stops helping and why sharding is the next step, and why replication is not a backup. CHAPTERS 0:00 Why one database isn't enough 0:43 One database doing everything 1:21 Primary and replicas 1:53 Read scaling 2:08 Primary-replica vs multi-primary 2:45 Write conflicts 3:18 Synchronous replication 4:29 Asynchronous replication 4:47 Replication lag 5:22 Read-your-own-writes 5:52 Failover 6:15 Split brain and lost writes 6:49 Where replication stops helping 7:27 Replication vs sharding 8:12 Replication is not a backup 8:43 The takeaway