3 ms·

Thanks for the link. > https://blog.dtornow.com/the-cap-theorem.-the-bad-the-bad-the-ugly/ https://blog.dtornow.com/the-cap-theorem.-the-bad-the-bad-th... Esp

by mrkeen 3y ago

Thanks for the link. > https://blog.dtornow.com/the-cap-theorem.-the-bad-the-bad-the-ugly/ https://blog.dtornow.com/the-cap-theorem.-the-bad-the-bad-th... Especially: > The “Pick 2 out of 3” interpretation implies that network partitions are optional, something you can opt-in or opt-out of. However, network partitions are inevitable in a realistic system model. Therefore, the ability to tolerate partitions is a non-negotiable requirement, rather than an optional attribute. > CAP requirements are absurd Yes! Literally. One would roundly ridicule someone who claimed to have met (or exceeded) those requirements.

andras_gerlits 3y ago
CAP means many different things. If you took the time to read what I have to say about it, you would know that I'm saying that we're beating the requirements Brewer sets out in his original presentation, where he introduces the concept of the C-A-P tradeoff. He's clearly wrong in what he says in the presentation, which is what we say we're beating. We can say this, because we're meeting the requirements for "C" there (DBMS-consistency) and because we don't suffer the trade-offs mentioned there. In fact, our system can be both available and partition-tolerant with a definition of "C" that matches the ones laid out in the SQL-spec, as the reads are always local. The SQL-standard doesn't mandate time-related availability guarantees for writes.