We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 8-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 Reliability Resilience
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”
In 2017, GitLab accidentally deleted a 300GB production database. They had five backup mechanisms configured: regular pg_dump, WAL-E streaming, LVM snapshots, Azure disk snapshots, and S3 . When they tried to restore, every single one had silently failed at some point in the past weeks. The incident became one of the most public data loss events in the industry and GitLab documented every painful hour of the 18-hour recovery on a public Google Doc.
Data redundancy is the practice of storing multiple copies of data across independent failure domains. It protects against hardware failure, software bugs, operator error, and regional disasters. The principle is simple: if you have N copies and a failure destroys one, you still have N-1 copies to serve from while you rebuild. The hard part is making sure those copies actually work when you need them.
Every database you rely on, Postgres, MySQL, DynamoDB, S3, uses some form of redundancy internally. But understanding how it works, what guarantees it provides, and where it breaks down is the difference between sleeping through an incident and spending 18 hours on a live-streamed recovery.
The factor (RF) determines how many copies of each piece of data exist. The quorum rules determine how many copies must agree for reads and writes to succeed.
| Config | RF | Write (W) | Read Quorum (R) | Consistency | Failure Tolerance |
|---|---|---|---|---|---|
| Minimum | 1 | 1 | 1 | Strong (trivially) | None. One disk dies, data is gone. |
| Standard | 3 | 2 | 2 | Strong (R+W > N) | Survives 1 replica failure |
| Read-optimized | 3 | 3 | 1 | Strong (R+W > N) | Writes block if any replica is down |
| High-durability | 5 | 3 | 3 | Strong (R+W > N) | Survives 2 simultaneous failures |
| Eventually consistent | 3 | 1 | 1 | Eventual | Fastest, but reads can return stale data |
Amazon's original Dynamo paper (2007) formalized this as the N/W/R model. DynamoDB, Cassandra, Riak, and CockroachDB all implement variations of it. The key formula: if R + W > N, every read sees the latest write. Break that inequality and you get eventual consistency.