Distributed Systems
Clocks: multiple-choice review
Crux Multiple-choice synthesis across the clocks unit: wall-clock skew, Lamport vs vector clocks, happens-before, concurrency detection, and TrueTime.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a real decision designing or debugging a distributed store — not a definition to recite, but a choice about how to order events when the wall clock lies.
Goal
Confirm you can connect clock skew, the choice between physical and logical clocks, Lamport vs vector semantics, happens-before, and TrueTime — the synthesis the lesson built toward.
Quiz
Completed
A Cassandra cluster uses last-write-wins on client timestamps. One node's clock is 1.5s behind. A user's later update routed through that node vanishes after a refresh, with a 200 OK returned. What is the root cause?
Heads-up The write was accepted and acknowledged; nothing was rolled back. It was lost later during timestamp-based conflict resolution — a silent drop, not a failed write.
Heads-up NTP shrinks skew on average but LWW fails on the worst case. A step can move a clock backward hundreds of ms, and a stalled ntpd or paused VM leaves seconds of skew — exactly the window that loses data.
Heads-up The newer write was permanently dropped by the LWW rule, not merely lagging. Read-repair propagates the surviving (wrong) value; it does not resurrect the discarded one.
Quiz
Completed
You need conflict resolution in a replicated KV store that must never silently drop a concurrent update. Lamport timestamps or vector clocks?
Heads-up A total order is the problem here, not the solution: Lamport imposes an arbitrary order on concurrent writes and cannot tell them apart from a causal chain, so the store deterministically picks one and drops the other.
Heads-up The semantics differ fundamentally. Lamport cannot detect concurrency at all; vector clocks can. Picking Lamport here means silently dropping concurrent writes, regardless of space.
Heads-up Wall-clock LWW is the exact failure being avoided; tighter NTP only narrows the window of loss. The requirement is to DETECT concurrency, which needs logical clocks.
Quiz
Completed
Lamport's clock guarantees that if A happens-before B then L(A) < L(B). Why can't you use L(A) < L(B) to conclude that A caused B?
Heads-up Ties are broken deterministically (e.g. by node id) to get a total order. The real gap is that the order is total even over events with no causal relation — concurrency is invisible.
Heads-up Overflow is an implementation footnote, not the semantic gap. The fundamental issue is that Lamport encodes a total order that cannot distinguish causality from concurrency.
Heads-up That is the exact misconception. Lamport gives consistency with causality (A before B implies a smaller timestamp) but not the converse; concurrent events get ordered anyway.
Quiz
Completed
Your vector clocks are correct, but a 200-node cluster now ships 200 counters of metadata with every write, and it grows as you add nodes. What is the real tradeoff you accepted?
Heads-up Lamport is O(1) but cannot detect concurrency — switching back reintroduces silent conflict drops. The cost is metadata size, not correctness; the answer is to prune, not abandon detection.
Heads-up The metadata is exactly what buys concurrency detection — the correctness benefit you needed. The tradeoff is space, not wasted cost.
Heads-up Vector clocks are O(n) in the number of nodes by construction; that growth is the whole reason production systems prune or scope the vectors.
Quiz
Completed
What does Spanner's TrueTime expose, and what does commit-wait do with it?
Heads-up TrueTime never claims an exact instant; it returns a bounded interval. Flushing to disk is durability, a separate concern — commit-wait specifically outlasts the ε uncertainty interval.
Heads-up That is lock contention, not commit-wait. Commit-wait is about clock uncertainty and overlaps with Paxos replication, so it often adds little real latency.
Heads-up There is no exact reading to converge on — TrueTime is an interval. Commit-wait sleeps out the interval rather than chasing agreement between reads.
Quiz
Completed
A delete in an LWW store occasionally suppresses every real write to a key for days, even writes that arrive long after the delete. What is the mechanism?
Heads-up LWW stores resolve by timestamp, not locks. The suppression comes from a future-dated tombstone winning every comparison, not a held lock.
Heads-up These writes are not lagging — they are stored and then lose the LWW comparison to a future-timestamped tombstone. Catching up does not help; the tombstone still wins.
Heads-up Indexing is unrelated. The writes are found and compared; they lose to the tombstone's larger timestamp until it is compacted away.
Recap
The through-line: wall-clock time is not an ordering primitive, so LWW turns skew into silent data loss (and future-dated tombstones into days-long key suppression). Logical clocks order by causality instead — Lamport gives a cheap O(1) total order but cannot detect concurrency, so vector clocks add a per-node counter to flag concurrent writes at O(n) metadata that must be pruned. TrueTime takes the third path: quantify clock uncertainty as a bounded interval ε and commit-wait it away for real external consistency. Choose the mechanism by what you must know — order, concurrency, or global truth.