Building distributed systems means dealing with network partitions, consistency trade-offs, and failure modes. Explore CAP theorem, eventual consistency models, and consensus algorithms like Raft and Paxos.
Markup Showcase: Distributed Systems
Headings and narrative
In unreliable networks, partitions are normal. Systems choose trade‑offs between availability and consistency. Client experience often improves with monotonic reads and read‑your‑writes guarantees.
Emphasis and links
See the excellent overview of CAP and Martin Kleppmann’s writing on eventual consistency. Internal notes live in the architecture docs.
Lists
- Partition tolerance is mandatory in distributed systems
- Choose between stronger consistency vs higher availability
- Session guarantees can improve UX
- Use CRDTs for conflict‑free merges
- Detect leader failure
- Elect new leader (Raft)
- Resume log replication
Quote: “The network is reliable” — a famous fallacy of distributed computing.
Inline code
Client sessions can pin to a leaderId and fall back when heartbeat timeouts occur.
Code blocks
Pseudo‑Raft (very simplified):
onHeartbeatTimeout() {
becomeCandidate();
requestVotes();
if (votes > quorum) becomeLeader();
}# Simulate packet loss with tc on Linux
sudo tc qdisc add dev eth0 root netem loss 10% delay 50ms 10ms distribution normaltype LogEntry = { index: number; term: number; data: Uint8Array };
function append(entries: LogEntry[], next: LogEntry) {
const last = entries.at(-1);
if (last && last.index + 1 !== next.index) throw new Error("hole in log");
return [...entries, next];
}Alignment table
| Model | Consistency | Availability | Notes |
|---|---|---|---|
| Single leader | Strong (R/W) | medium | failover required |
| Leader + followers | Strong (R/W) | high | read replicas possible |
| Multi‑leader | Eventual | high | conflict resolution |
| Leaderless (quorum) | Tunable (R/W) | high | choose R/W quorums |
Horizontal rule
Sub/sup and long URL
Replication factor Rf=3 is common; latency p95th should remain stable under node loss.
