What survives a failure?
I’m Madhurya, a software engineer working on distributed systems. I’m interested in what keeps them correct when things go wrong.
The engineer behind the labBreak a replica.
Watch the boundary.
Interactive modelRuns in your browser
Select a replica to take it offline. Try two failures, then three.
Writes available5 reachable · 3 required
0committed writes
Ready. A write needs at least 3 of the 5 replicas.
A majority-availability model, not a Raft or Paxos simulator. Recovery assumes retained data and immediate catch-up; no elections, latency, or disk failures. See the assumptions.
A majority is a start.
Not the whole story.
Three acknowledgements tell you something. They do not, by themselves, prove that a distributed system is correct.
Go beyond the diagram: quorum intersection, the meaning of a committed write, and the failure modes this little model leaves out.
Read the lab notesReliability lives
in the details.
My focus is distributed systems, databases, and reliable infrastructure. This is a place to make the trade-offs visible—one small, explicit model at a time.
Connect on LinkedIn