We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Database Fundamentals
Free preview: the first 2 parts of this 11-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Database Fundamentals
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You run a successful e-commerce site. All your data, users, orders, inventory, lives on one database server. One night, the server's disk fails. Your database is gone. Your site is down. Your customers are furious.
"But we had backups!" Sure. But restoring a backup takes hours. During those hours, every new order, every cart update, every user signup is lost. And if the backup is from last night, you've also lost an entire day of data.
This is why every serious production system uses database , maintaining multiple copies of the same data on different servers, in real time. If one server dies, another takes over in seconds, not hours.
But replication isn't just about failure. It's also about performance. Why force all reads through one server when you could spread them across five? Replication lets you scale reads horizontally, serve users from geographically closer servers, and run expensive analytics queries on a replica without impacting your production database.
Every major company does this. Amazon, Google, Netflix, Uber, they all replicate their databases. The question isn't whether to replicate, but how.
Database is the process of copying data from one database server (the primary or leader) to one or more other servers (the replicas or followers), so that every server has the same data.
When a write happens on the primary, it must propagate to all replicas. When a read happens, it can be served by the primary or any replica.
The core challenge: keeping all copies in sync. This is harder than it sounds, because:
These constraints force every replication system to make trade-offs between consistency (are all replicas identical?), availability (can the system serve requests if a server fails?), and performance (how fast are reads and writes?).
This is the in practice. Replication is where it stops being academic and starts being real.