Cap Theorem hard
Jepsen testing often reveals that databases configured for 'Strong Consistency' fail to uphold it during partitions. Which failure mode is most common?
- A Split Brain: Two nodes independently accept conflicting writes, leading the system to later discard the minority side's data upon recovery.
- B Total Network Cessation: The database becomes completely unavailable for all requests, which is actually the correct and expected CP behavior.
- C Recursive Error Generation: The primary database cluster enters a permanent error loop that requires a full manual system reset to resolve.
- D Localized Kernel Panics: The database engine crashes at the OS level due to unhandled exceptions in the distributed consensus module.
Answer: A. Split Brain: Two nodes independently accept conflicting writes, leading the system to later discard the minority side's data upon recovery.
Jepsen tests (by Kyle Kingsbury) have famously shown that many databases with 'Strong Consistency' claims actually suffer from data loss during partitions. A common failure is when a partitioned node incorrectly thinks it is still the leader and continues to acknowledge writes. When the network heals, the system's reconciliation logic (like Last-Write-Wins) silently overwrites or rolls back those 'acknowledged' writes to match the majority.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- What is a 'Split Brain' scenario?
- The PACELC theorem extends CAP by stating: Even when there is NO partition (E), the system must choose between:
- Why is a CA (Consistent + Available) system generally considered impossible for distributed web applications?
- In CAP, 'Consistency' is equivalent to:
- In the CAP Theorem, what does the 'P' stand for?
- What causes a Network Partition?