Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The CAP argument falls apart as soon as you decouple consistency from wall-clocks. Consistent systems only suffer from CAP limitations if they need strict serializability.

The point is that if you only look at the order of the data and not the wall-clock of some actor in the system, you can "calibrate" these separate ordering mechanisms together into a coherent whole and from that, you can build up all of the SQL guarantees.

Linearizability makes systems suffer because it tries to enforce a Newtonian model in a relativistic world. Order will naturally emerge faster when you're closer to the data than if you're farther. Measuring these with the same clock is what causes CAP, not some inherent property of distributed consistency.



> The CAP argument falls apart as soon as you decouple consistency from wall-clocks

Hogwash

Five friends are seated at a restaurant, about to agree on a flavour of pizza via a simple majority quorum. Before they do so, the three girls excuse themselves to the restroom while the two boys remain at the table. The waiter arrives and asks what flavour pizza they'll have.

Do the two boys answer on behalf of all five friends, or do they wait for the girls to return?

No-one checked their own watch.


Can I replicate people deterministically and control all their sensory inputs in this scenario?


There's 0 relativity involved in distributed databases


Yes, that's exactly the problem with the existing models and why CAP was formalised.


Nope, that's not true, and you neither solved nor explained it in this message




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: