Distributed systems
Что происходит, когда система живёт на нескольких узлах: частичные отказы, ненадёжные часы и сеть, линеаризуемость и CAP, консенсус и кворумы, сквозной аргумент и правда об exactly-once.
Why it matters. The moment a service stops being one process on one machine, a class of problems appears that a monolith never had: a node isn't answering — but is it alive, clocks have drifted, a message arrived twice. This section is about the nature of those problems and which guarantees are achievable at all. Part of the training program.
Three articles: what exactly breaks, which guarantees you can buy, and how to reason about correctness as a whole.
Articles in the section
- Trouble with distributed systems — partial failures, unreliable clocks and networks, truth by quorum.
- Consistency and consensus — linearizability, CAP, and why one common problem hides behind every agreement task.
- Correctness in a distributed system — the end-to-end argument, the truth about exactly-once, integrity vs timeliness.
Related
- Data foundations — replication and sharding, the reason there are many nodes in the first place.
- Distributed patterns — outbox, saga, idempotency: the cures for what's described here.
- Resilience — timeouts, retries, circuit breaker.
- System design — the method whose "behavior under failure" step brings all of this up.