4 ms·
Once it's clear what the terms mean, the theorem is so obvious as to scarcely need proof. If G1 and G2 can never talk to each other, of course you can't write d
by gweinberg 8y ago
Once it's clear what the terms mean, the theorem is so obvious as to scarcely need proof. If G1 and G2 can never talk to each other, of course you can't write data to G1 and read it back from G2.
I think the point is more about timing. If your client writes to G1, then you pretty much have to wait until the write has propagated to the entire network to acknowledge the write or accept some risk that some other client will read back stale data after the write has been acknowledged. I should think this would be obvious to coders also, but it is not at all obvious to managers.
I say "pretty much" above because there is technically a ridiculous third option where you essentially lock down the whole network with every read. But it still doesn't get you around CAP.
- thanatos_dem 8y agoThe combination of partition tolerance being mandatory and the timing caveat is why I prefer to think in terms of an extended CAP theorem called PACELC[1]. The first part, PAC, is your traditional CAP theorem - in the presence of partitions (P), you can provide either availability (A), or consistency (C). The second part, ELC, describes the system characteristics during the normal, non-partition case. It reads as "else (E), you can provide either low latency (L) or consistency (C)". Even tho apart from some curious outliers most systems are either PA/EL or PC/EC, I find the framing helpful for reasoning about a system in more than just the partition or failure case. [1] https://en.wikipedia.org/wiki/PACELC_theorem https://en.wikipedia.org/wiki/PACELC_theorem
- martincmartin 8y agoYour first paragraph is spot on. The rest is overstating things though. "If your client writes to G1, then you pretty much have to wait until the write has propagated to the entire network to acknowledge the write" PAXOS, for example, just needs it to be written to a majority of nodes. If you write it to node "key % n", where n is the number of nodes, then only that single node needs to be up & available to all writers / readers.