Beating the CAP Theorem Checklist
Aug. 15th, 2013 10:47 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
wizzardYour ( ) tweet ( ) blog post ( ) marketing material ( ) online comment
advocates a way to beat the CAP theorem. Your idea will not work. Here is why
it won't work:
( ) you are assuming that software/network/hardware failures will not happen
( ) you pushed the actual problem to another layer of the system
( ) your solution is equivalent to an existing one that doesn't beat CAP
( ) you're actually building an AP system
( ) you're actually building a CP system
( ) you are not, in fact, designing a distributed system
Specifically, your plan fails to account for:
( ) latency is a thing that exists
( ) high latency is indistinguishable from splits or unavailability
( ) network topology changes over time
( ) there might be more than 1 partition at the same time
( ) split nodes can vanish forever
( ) a split node cannot be differentiated from a crashed one by its peers
( ) clients are also part of the distributed system
( ) stable storage may become corrupt
( ) network failures will actually happen
( ) hardware failures will actually happen
( ) operator errors will actually happen
( ) deleted items will come back after synchronization with other nodes
( ) clocks drift across multiple parts of the system, forward and backwards in time
( ) things can happen at the same time on different machines
( ) side effects cannot be rolled back the way transactions can
( ) failures can occur while in a critical part of your algorithm
( ) designing distributed systems is actually hard
( ) implementing them is harder still
And the following technical objections may apply:
( ) your solution requires a central authority that cannot be unavailable
( ) read-only mode is still unavailability for writes
( ) your quorum size cannot be changed over time
( ) your cluster size cannot be changed over time
( ) using 'infinite timeouts' is not an acceptable solution to lost messages
( ) your system accumulates data forever and assumes infinite storage
( ) re-synchronizing data will require more bandwidth than everything else put together
( ) acknowledging reception is not the same as confirming consumption of messages
( ) you don't even wait for messages to be written to disk
( ) you assume short periods of unavailability are insignificant
( ) you are basing yourself on a paper or theory that has not yet been proven
Furthermore, this is what I think about you:
( ) nice try, but blatantly false advertising
( ) you are badly reinventing existing concepts and should do some research
( ) in particular, you should read the definition of the word 'theorem'
( ) also you should read the definition of 'distributed system'
( ) you have no idea what you are doing
( ) do you even know what a logical clock is?
( ) you shouldn't be in charge of people's data
from http://ferd.ca/beating-the-cap-theorem-checklist.html
P.S. Я еще помню у Patrick McKenzie чеклисты про имена и даты, а какие еще вы знаете?
advocates a way to beat the CAP theorem. Your idea will not work. Here is why
it won't work:
( ) you are assuming that software/network/hardware failures will not happen
( ) you pushed the actual problem to another layer of the system
( ) your solution is equivalent to an existing one that doesn't beat CAP
( ) you're actually building an AP system
( ) you're actually building a CP system
( ) you are not, in fact, designing a distributed system
Specifically, your plan fails to account for:
( ) latency is a thing that exists
( ) high latency is indistinguishable from splits or unavailability
( ) network topology changes over time
( ) there might be more than 1 partition at the same time
( ) split nodes can vanish forever
( ) a split node cannot be differentiated from a crashed one by its peers
( ) clients are also part of the distributed system
( ) stable storage may become corrupt
( ) network failures will actually happen
( ) hardware failures will actually happen
( ) operator errors will actually happen
( ) deleted items will come back after synchronization with other nodes
( ) clocks drift across multiple parts of the system, forward and backwards in time
( ) things can happen at the same time on different machines
( ) side effects cannot be rolled back the way transactions can
( ) failures can occur while in a critical part of your algorithm
( ) designing distributed systems is actually hard
( ) implementing them is harder still
And the following technical objections may apply:
( ) your solution requires a central authority that cannot be unavailable
( ) read-only mode is still unavailability for writes
( ) your quorum size cannot be changed over time
( ) your cluster size cannot be changed over time
( ) using 'infinite timeouts' is not an acceptable solution to lost messages
( ) your system accumulates data forever and assumes infinite storage
( ) re-synchronizing data will require more bandwidth than everything else put together
( ) acknowledging reception is not the same as confirming consumption of messages
( ) you don't even wait for messages to be written to disk
( ) you assume short periods of unavailability are insignificant
( ) you are basing yourself on a paper or theory that has not yet been proven
Furthermore, this is what I think about you:
( ) nice try, but blatantly false advertising
( ) you are badly reinventing existing concepts and should do some research
( ) in particular, you should read the definition of the word 'theorem'
( ) also you should read the definition of 'distributed system'
( ) you have no idea what you are doing
( ) do you even know what a logical clock is?
( ) you shouldn't be in charge of people's data
from http://ferd.ca/beating-the-cap-theorem-checklist.html
P.S. Я еще помню у Patrick McKenzie чеклисты про имена и даты, а какие еще вы знаете?
