Two coding angles on staleness
Timestamped reads — clients ask "what was the value at time T?" Storage engines and caches expose this pattern (snapshot reads, versioned cells). LeetCode's Time Based Key-Value Store is a simplified autograded version.
Version vectors — replicas track per-node counters; dominance detects ordering vs concurrency. You implement the compare/merge logic locally — the same rules behind Dynamo-style conflict detection (Topic 5).
Neither exercise needs multiple processes. They train the semantics you'll defend in system design.
Link to interview loops
- "Can a read return stale data under R=2, W=2, N=5?" → quorum task in the next subtopic.
- "How do you detect concurrent writes?" → vector clock
comparereturningconcurrent. - "How does a session guarantee read-your-writes?" → often pinned to a primary or version check — Time Based KV is a toy version index.
Practice order
- Code vector clock
compare+merge(task spec). - Solve Time Based Key-Value Store on LeetCode (optional problem).
- Explain aloud how you'd upgrade the LeetCode store to multi-replica staleness bounds.
Further Reading
Coding Exercises (Optional)
In-memory specs — implement locally with unit tests. No cluster, Docker, or cloud setup unless a task says otherwise.
- Code: Vector clock compare25m
Implement `compare(a: number[], b: number[]) -> "before" | "after" | "concurrent" | "equal"` for same-length version vectors (one slot per replica id). Rules: if all a[i] ≤ b[i] and at least one strict < → `before`; mirror for `after`; if equal slot-wise → `equal`; else → `concurrent`. Add `merge(a, b) -> number[]` taking element-wise max. Unit-test: [2,1,0] vs [1,2,0] → concurrent; dominance chain; merge after concurrent writes. ~25 minutes.
Autograded Problems (Optional)
External judges (LeetCode). Same distributed concepts — solve in your editor, submit on the platform.
- Time Based Key-Value StoreMedium3/530m