Consistency Patterns — Series 2

Preview — 3 of 10 questions

Two replicas of a distributed key-value store each accept a write to the same key while unable to communicate with each other. When they reconnect, how does a vector clock help determine whether one write happened before the other, or whether they're genuinely concurrent (conflicting) updates?

AA vector clock is a physical wall clock synchronized via NTP across all replicas, used to compare real-world timestamps directly

BA vector clock is a per-key counter that only ever increases on the primary replica, with all other replicas ignoring it entirely

CA vector clock attaches a small array of per-replica counters to each version of the data — each replica increments only its own counter on a local write. Comparing two vector clocks tells you whether one is a strict descendant of the other (meaning it causally happened after, incorporating the earlier one's knowledge) or whether neither dominates the other (meaning the two writes happened concurrently, without either replica knowing about the other's update) — a genuine conflict that needs resolving

DVector clocks can only be used in systems with exactly two replicas, never more

When two replicas produce conflicting concurrent writes to the same key, last-write-wins (LWW) is one simple way to resolve the conflict. How does it work, and what's its main downside?

ALWW means both conflicting writes are always kept and merged together automatically into a single combined value, with no data loss

BLWW requires manual human review of every single conflict before any write can be resolved

CLWW is only applicable to numeric data types and cannot be used for any other kind of value

DLWW resolves a conflict by attaching a timestamp to each write and simply keeping whichever write has the latest timestamp, discarding the other — simple and requires no application-level merge logic, but its main downside is that the discarded write is silently lost entirely, and if clocks aren't perfectly synchronized across replicas, "latest timestamp" might not actually correspond to what really happened last in real time

Distributed systems often need multiple nodes to agree on a single value or ordering of operations, even if some nodes fail or messages are delayed. At a high level, what problem do consensus algorithms (like Paxos or Raft) solve, and why is it hard?

AConsensus algorithms let a group of nodes agree on a single, consistent value or sequence of operations despite some nodes crashing, being slow, or messages being delayed or lost — the difficulty comes from having to guarantee this agreement is reached correctly (and that once agreed, it can't later be silently contradicted) even though no node can fully trust what any other node claims or perfectly know whether another node has actually failed or is just slow

BConsensus algorithms exist purely to encrypt data in transit between nodes, unrelated to agreement or ordering

CConsensus is trivially solved by simply having every node independently pick whichever value it personally prefers

DConsensus algorithms only work if every single node in the cluster is guaranteed to never fail, ever

Answer all 10 questions (7 more), see explanations for every answer, and track your score.