Chapter 1 · Watch, then practise
Introduction
Reason about independent component failures through a client–server exchange. Identify what each side can actually know.
3 questions · 3 with related videos. Matches are based on playlist titles; broader background matches are labeled.
What to study
- Message passing
- Partial failure
- Latency and reliability
Chapter playlists
Choose a playlist
Notes
Distributed Systems 2.3: System models
Martin Kleppmann · 20:45
Supplementary system-model lecture for network uncertainty and partial failure.
1. Why distribution is different
What new uncertainty appears when a function is implemented by a remote server?
The request or reply may be lost, the network may be delayed, or the server may fail while the client continues running. Communication takes time and does not share a single machine’s failure boundary. Remote execution therefore needs explicit failure handling.
Distributed Systems 2.3: System models
Martin Kleppmann · 20:45
System-model discussion supports distinguishing a timeout from proof of failure.
2. A missing reply
A client sends a request but receives no reply before its timeout. What can it conclude?
Only that no reply arrived within the chosen interval. It cannot distinguish a slow server, a lost message and a failed server from that observation alone. A timeout is a suspicion used to guide recovery, not proof of failure.
Distributed Systems in One Lesson by Tim Berglund
Devoxx Poland · 49:00 · Background lecture
Distributed-systems background for the availability and coordination tradeoff.
3. An application tradeoff
Why can adding servers improve availability yet make a service harder to build?
Another server may continue when one fails, but replicas must coordinate state and clients need a way to find usable servers. More machines introduce additional communication, consistency and failure-recovery work; redundancy alone does not ensure correct behavior.