☒ Beating the CAP Theorem Checklist
Your blog/presentation/post/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:
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
Source: https://ferd.ca/beating-the-cap-theorem-checklist.html
#architecture #distributed_system
Your blog/presentation/post/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 provenFurthermore, 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
Source: https://ferd.ca/beating-the-cap-theorem-checklist.html
#architecture #distributed_system