Checklist for overcoming the CAP-theorem

So, you ☐ tweeted, wrote a blog, published a press release, wrote in the comments that you know a way to overcome the CAP-theorem . Your idea won't work. And that's why:

You assume that software / hardware / network failures never happen
☐ you really just transferred the problem to another logical layer
☐ your solution is equivalent to one already existing, which does not overcome the CAP-theorem
You actually built the AP-system (availability and resistance to separation, but not constant data consistency)
You actually built a CP system (data consistency and separation tolerance, but not permanent availability)
☐ you actually built an unallocated system

And especially in your plans the following is bad:

☐ delay is a real thing
☐ big delay is the same as service unavailability
network topology changes over time
☐ network separation can occur in more than one place
☐ the separated part of the network may disappear forever
☐ the temporarily separated part of the network for the rest of the system is indistinguishable from the completely falling
☐ clients are also part of a distributed system
☐ stable data storage may be unstable
☐ network failures will happen
☐ iron malfunctions will occur
☐ human errors will happen
☐ deleted data will recover after synchronization with previously dropped nodes
☐ due to time stamp differences, your data will travel back and forth in time
☐ things happen simultaneously on different machines
☐ some side effects cannot be rolled back, like a transaction
☐ failures occur in the most critical parts of your system
☐ to design a distributed system is really hard
☐ and implement - even harder
')
Plus, more such technical difficulties may arise:

Your solution requires a central component that cannot be unavailable
☐ It turns out that in the read-only mode the recording
☐ the size of the quorum group on your system cannot be changed
☐ cluster size on your system cannot be changed
☐ using "infinite timeout" is not a solution to the problem of lost messages.
Your system assumes data storage forever, for which, of course, you need dimensionless storage
☐ resynchronization of data will require more traffic than anything else taken together
☐ “confirmation of receipt” is not the same as “confirmation of processing”
You don't even wait for the data to be written to disk
☐ you assume that small periods of inaccessibility are acceptable
You are based on a theory that so far is only on paper

And that's what I think of you:

Great try, but blatantly wrong advertising
☐ you have re-invented an existing technology, and you did it badly
☐ Well, in general, read the definition of the term "theorem"
☐ and another term "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 other people’s data