Distributed Systems, Like It or Not
summary
Argument: distributed systems are now everywhere so failures matter because one node can affect 10 million browser nodes not just one user; timing and clocks are the real root cause, so the talk focuses on concrete tools and concepts used to reason about failures: Lamport timestamps, Paxos and Raft consensus, vector clocks, Spanner-style synchronized time, circuit-breaker timing pathologies, and new edge-mesh/WebRTC failure modes. Examples include train-like timeout pathologies, why clock disagreement breaks causal reasoning, and when consensus implementations succeed or silently fail.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 1:42Software Development
- 2:54Distributed Software
- 4:12Distributed Applications
- 6:18Distributed Systems
- 9:06DNS
- 10:49Systems progression
- 14:34iPhone analogy
- 15:37Understanding time
- 21:31Causal thinking
- 21:51Failures around timing
- 22:11Timeouts
- 23:06Consensus
- 23:38Troubleshooting
- 23:53What do we get
- 25:03The problem
- 25:23Pathology
related talks
28mWhy Are Distributed Systems So Hard?
43mWhat We Talk About When We Talk About Distributed Systems
33mWhy Are Distributed Systems So Hard?
29mHorrors of Distributed Systems
52mDistributed Computing Dealing with Time and Failure in the Wild
47mAdventures in Spacetime
44mDistributed systems and scalability rules
25mGrowing Distributed Systems