3 ms·
> No you can't, not without breaking the rules of the system, because as you say, that would lead to an actually inconsistent system. If you want to redefine e
by eloff 5y ago
> No you can't, not without breaking the rules of the system, because as you say, that would lead to an actually inconsistent system.
If you want to redefine eventually consistent to prohibit that behavior then you've just reclassified most real life AP systems as eventually inconsistent.
Eventually consistent systems allow stale reads of older data plus deleted data for an undefined period of time. If you turn around and issue a write based on that you get inconsistency. Eventually consistent systems do not prohibit this.
> Nonsense. CPUs only work on very limited data structures (sequences of bits), but that's not a concern in practice because we can build up more complicated datastructures on top of them. The same is true for CRDTs.
You're talking like there are no downsides to CRDTs. There are huge downsides to them, which is why they're rarely used in practice. Your analysis is only valid in theory.
- ledauphin 5y agoI would appreciate some information specifically about the problems that cannot be solved by building abstractions on top of CRDTs. I don't don't they exist.
- eloff 5y agoWhat data structures can't be implemented efficiently? Or what applications can't be architected differently to utilize CRDTs?
- lmm 5y ago> Eventually consistent systems allow stale reads of older data plus deleted data for an undefined period of time. If you turn around and issue a write based on that you get inconsistency. Eventually consistent systems do not prohibit this. An eventually consistent system does prohibit that, because as you say it would lead to inconsistency. If you want to do a write based on a read, you're supposed to express that using the system's abstractions, so that a change in the input will (eventually) be propagated to a change in the output. > You're talking like there are no downsides to CRDTs. There are huge downsides to them, which is why they're rarely used in practice. Your analysis is only valid in theory. In my experience the "downside" is that you have to actually take 5 minutes to think about your datamodel. They're very much effective in practice. I use them all the time.