CAP and PACELC
0-day streakReview

Your progress

Level 1

0 XP100 XP to level 2
0day streak
0best streak
0topics started
0cards reviewed
    Review cards

    Progress is stored only in this browser. No account is required.

    CAP theorem and PACELC: the 60-second story

    CAP and PACELC

    The phone line dies with one berth left.

    Two booking counters share a ledger and phone each other after every sale. Now a passenger walks up to each. Sell, or wait?

    During a partition, a replica answers stale or not at all.

    A write reached G1; G2 heard nothing. If G2 answers 0, consistency breaks. If it waits or errors, availability breaks.

    Pick any two of three?

    Bad: Choose CA

    You can’t opt out of partitions. One side still stops or diverges.

    Good: Partition? Then C or A

    Only while it lasts, give up fresh answers or give up answering.

    A server can’t tell a cut link from a slow one. It waits on a replica; the timer fires.

    The trick

    CAP is a timeout decision: cancel and lose availability, or proceed and risk consistency.

    Same partition: CP refuses the minority, AP accepts and merges later.

    CP isn’t “down”; the majority keeps working. AP answers everyone, then pays in conflicts that must be merged.

    10 ms

    of round trip per 1,000 km of fibre

    PACELC’s else. With no partition at all, every replica you wait for still costs a round trip. Mumbai to Singapore is at least 40 ms.

    Per operation, is a wrong answer worse than no answer?

    Money or a double-sold berth? Choose consistency. A blank feed or a frozen map? Choose availability, and plan the merge.

    The label belongs to a setting, not a product

    1. Cassandra at ONE behaves PA/EL
    2. At QUORUM, the minority side fails, near PC/EC
    3. Leader + async replicas: neither CAP-consistent nor CAP-available

    Remember

    During a partition, each operation answers stale or not at all. Else, it trades latency for consistency. The ledger is PC/EC; likes are AP/EL.