Revision Cheat Sheet
By Pritesh Yadav 3 min read —
The 8 Fallacies of Distributed Computing (all are FALSE)
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology doesn't change
- There is one administrator
- Transport cost is zero
- The network is homogeneous
If you remember only one: "the network is reliable" is false. Assume messages can be slow, lost, duplicated, reordered, or cut off entirely — and a slow message is indistinguishable from a lost one.
Fault vs Failure
| Term | Meaning | Goal |
|---|---|---|
| Fault | One component goes wrong (disk, packet, node) | Tolerate it |
| Failure | The whole system stops doing its job | Prevent it |
Happens-Before (A → B) rules
- Same node, in order: if A then B on one machine, A → B.
- Message: sending a message → receiving that message.
- Transitive: if A → B and B → C, then A → C.
- Concurrent: if neither A → B nor B → A, they are concurrent (independent).
Lamport vs Vector Clocks
| Lamport clock | Vector clock | |
|---|---|---|
| Size | One number per node | One number per node, per node (a list) |
| On local event | counter += 1 | increment own slot |
| On send | send counter with message | send whole vector |
| On receive | counter = max(local, received) + 1 | take max of each slot, then increment own |
| Tells you A→B? | Guarantees A→B ⇒ A<B (but A<B doesn't prove A→B) | Yes — can prove A→B, B→A, or concurrent |
| Detects concurrency? | No | Yes |
Comparing two vectors: if every slot of V1 ≤ V2 (and at least one is strictly less), then A → B. If some slots are bigger and some smaller, the events are concurrent.
CAP & PACELC one-liners
- CAP: during a network Partition, choose Consistency or Availability — you can't keep both.
- Partition tolerance is mandatory on real networks, so CAP is really just C vs A.
- CP system: refuses some requests during a split to avoid stale data.
- AP system: always answers, may return stale data and reconcile later.
- PACELC: if Partition → A vs C; Else → Latency vs C. The consistency cost exists even when nothing is broken.
Consistency model ladder (strongest → weakest)
| Model | Promise in plain English |
|---|---|
| Linearizable (strongest) | Acts like one copy; every read sees the latest write, instantly. |
| Sequential | Everyone sees operations in the same order, but not necessarily real-time. |
| Causal | Cause is always seen before effect; unrelated events may differ in order. |
| Read-your-writes / Monotonic reads | You always see your own changes and never go backwards in time. |
| Eventual (weakest) | If writes stop, all copies eventually match. Reads may be stale meanwhile. |
Rules of thumb
- Never order events across machines by wall-clock time — use logical clocks.
- NTP narrows clock skew, it never removes it. Assume milliseconds of error.
- Make every retried operation idempotent — you can't tell a lost request from a lost reply.
- Pick the weakest consistency model that is still correct for the use case — stronger costs latency and availability.
- Stale ≠ wrong. Eventually consistent data is just behind, not corrupt.
- Use a quorum ("more than half") so two conflicting decisions can never both win.
- Design to stop faults from becoming failures — faults are constant and normal.