4 ms·

Eventual consistency is a stronger guarantee than you get with a remote git repo. It actually works fine for a large number of use cases. CRDTs are just a way

Eventual consistency is a stronger guarantee than you get with a remote git repo. It actually works fine for a large number of use cases. CRDTs are just a way of implementing eventual consistency in provably predictable and 'reasonable' manners. I will agree they are very limited data structures, but I disagree that they only work for very simple situations. I'd liken them to an immutable list in FP. Very limited data structure, but can be used cleverly to create very complicated ones that maintain the same invariants.

loopz 5y ago
If it's anything used by Netflix, Amazon Prime, Facebook, etc. it's inconsistent in practice. Maybe some of them does it right, but updates seems to be lost often. Perhaps something else than CRDTs is used though.
- lostcolony 5y ago
  So, CRDTs are just a tool at the data layer to provide a way to resolve inconsistencies. A simple and easily understood example is an add-only set; in the event there is inconsistency it can be automatically resolved; the consistent state is just the union of the sets. Now, while that model will give you predictable behavior to resolve inconsistencies, it's still eventually consistent (well, hopefully; CRDTs, being a data structure, also don't enforce that the system actually resolves those inconsistencies, just guarantees that it can do so in a correct way). And it doesn't tell you anything about the rest of the system. I.e., even using CRDTs, if I have an internal netsplit, if you write to one partition, and read from the other, you will miss data (and if I try to read again, I might read from the partition I wrote to, so some reads return state T, and some reads return state T-1, until the consistency is resolved). The benefit to CRDTs is that when the consistency is resolved (no guarantees on when that will be, or that the system as a whole ensures it!), I've definitely moved forward in time. Not all conflict resolution mechanisms provide that guarantee. For instance, Cassandra's (which came out of Facebook) old default (maybe current, I haven't used it in a while) of "Last Write Wins" meant that clock drift could lead to weirdness. I.e., at my time T I write X = 1. At my time T+1 I write X = 2. HOWEVER, the clock providing the timestamp of the change for the second is lagging, and thinks it's actually T-1. When the system deconflicts, T > T-1, so X will remain equal to 1, even though from a true temporal sense I know that X should be equal to 2.

loopz 5y ago

If it's anything used by Netflix, Amazon Prime, Facebook, etc. it's inconsistent in practice. Maybe some of them does it right, but updates seems to be lost often. Perhaps something else than CRDTs is used though.

lostcolony 5y ago
So, CRDTs are just a tool at the data layer to provide a way to resolve inconsistencies. A simple and easily understood example is an add-only set; in the event there is inconsistency it can be automatically resolved; the consistent state is just the union of the sets. Now, while that model will give you predictable behavior to resolve inconsistencies, it's still eventually consistent (well, hopefully; CRDTs, being a data structure, also don't enforce that the system actually resolves those inconsistencies, just guarantees that it can do so in a correct way). And it doesn't tell you anything about the rest of the system. I.e., even using CRDTs, if I have an internal netsplit, if you write to one partition, and read from the other, you will miss data (and if I try to read again, I might read from the partition I wrote to, so some reads return state T, and some reads return state T-1, until the consistency is resolved). The benefit to CRDTs is that when the consistency is resolved (no guarantees on when that will be, or that the system as a whole ensures it!), I've definitely moved forward in time. Not all conflict resolution mechanisms provide that guarantee. For instance, Cassandra's (which came out of Facebook) old default (maybe current, I haven't used it in a while) of "Last Write Wins" meant that clock drift could lead to weirdness. I.e., at my time T I write X = 1. At my time T+1 I write X = 2. HOWEVER, the clock providing the timestamp of the change for the second is lagging, and thinks it's actually T-1. When the system deconflicts, T > T-1, so X will remain equal to 1, even though from a true temporal sense I know that X should be equal to 2.