Two users simultaneously update the same database record on different replicas in a multi-master system using last-writer-wins conflict resolution. User A's write has a slightly earlier timestamp than User B's write. What happens to User A's write?
AUser A's write is preserved and User B's write is rejected with an error
BBoth writes are merged using application logic to produce a combined result
CUser A's write is silently discarded — last-writer-wins keeps only the write with the later timestamp
DThe system enters a conflict state and blocks all reads until an administrator resolves the conflict
Last-writer-wins (LWW) resolves conflicts by comparing timestamps and keeping the write with the later timestamp — User B's write wins. User A's write is silently discarded; the user receives no error and may not know their update was lost. This is the core tradeoff of LWW: it is simple and always converges, but it can silently lose data. Systems using LWW accept that concurrent conflicting updates will result in one update being lost, which is acceptable for some applications (shopping cart preferences) but catastrophic for others (financial records).
Question 2 Multiple Choice
A multi-master system uses a consensus protocol (Raft) on every write to ensure strong consistency. A developer argues this defeats the purpose of multi-master replication. Why is this criticism valid?
ARaft consensus only works with at most 3 replicas, limiting geographic distribution
BRaft consensus requires that all write requests go through a single elected leader, eliminating multi-master semantics
CRequiring cross-replica consensus coordination before confirming each write reintroduces latency that multi-master was intended to avoid
DRaft consensus is incompatible with geographically distributed deployments because it requires synchronous communication
The primary motivation for multi-master replication is low-latency local writes — a user in Tokyo writes to a Tokyo replica without waiting for coordination with London. When Raft consensus is required for every write, the write cannot be confirmed until replicas agree on its ordering, which requires round-trip communication across geographic distances. A user in Tokyo now waits for a response from London before their write completes. The latency advantage of local writes is largely eliminated. This is the core tension: strong consistency (via consensus) and low-latency local writes cannot both be achieved simultaneously in geographically distributed systems.
Question 3 True / False
CRDTs (conflict-free replicated data types) are designed so that concurrent operations on different replicas always converge to the same final state, regardless of the order in which updates are applied.
TTrue
FFalse
Answer: True
CRDTs achieve this through careful mathematical design. The data structure and its merge operations are constructed so that concurrent updates commute — applying them in any order produces the same result. For example, a grow-only set CRDT simply takes the union of all elements seen across replicas; adding the same element on two different replicas simultaneously always produces the correct merged result. CRDTs eliminate the need for conflict resolution logic because conflicts are structurally impossible — the data type constrains operations to those that are always safe to merge.
Question 4 True / False
A multi-master system using eventual consistency provides strong consistency because most replicas will eventually agree on the same value.
TTrue
FFalse
Answer: False
Eventual consistency means replicas converge to the same state *eventually* if no new writes arrive — but during the window before convergence, different replicas may return different values for the same key. This is fundamentally different from strong consistency, which guarantees that all reads reflect the most recent write. A system could return stale or conflicted values to users for seconds, minutes, or longer under eventual consistency. 'Eventually the same' is not the same as 'always the same right now.' The CAP theorem formalizes this: under network partitions, you must choose between consistency (always correct) and availability (always respond), not both.
Question 5 Short Answer
Why can't a multi-master replication system simultaneously achieve low-latency local writes, strong consistency, and high availability during network partitions? What tradeoff must be made?
Think about your answer, then reveal below.
Model answer: Strong consistency requires that all replicas agree on the value before a write is confirmed — which requires cross-replica communication (consensus). This communication introduces latency proportional to network round-trip time between replicas. During a network partition, replicas cannot communicate, so a strongly-consistent system must either refuse writes (sacrificing availability) or accept writes and risk inconsistency. Low-latency local writes require accepting a write immediately on one replica without coordination — which means other replicas are temporarily inconsistent. The CAP theorem captures this: a distributed system can at most provide two of consistency, availability, and partition tolerance. Multi-master systems typically choose between strong consistency with higher latency (consensus-based, like Spanner) or high availability with eventual consistency (like CouchDB), but cannot achieve all three simultaneously.
The tradeoff is not a bug to be engineered away — it is a fundamental property of distributed systems formalized by the CAP theorem. Understanding this forces deliberate design choices: what does your application need most? Financial systems that cannot tolerate inconsistency choose consistency. User-facing applications that cannot tolerate unavailability choose availability. The choice of replication topology and conflict resolution strategy flows directly from this answer.