The majority of the content reminds me of Bigtable (https://static.googleusercontent.com/media/research.google.c...).

Do people really distinguish "Strong Eventual Consistency" from "Eventual Consistency"? To me, when I say "Eventual Consistency" I alwayes mean "Strong Eventual Consisteny".

▲

nl 5 days ago | parent | next [-]

(Non-Strong) Eventual Consistency does not guarantee that all replicas converge in a specific time period.

In an eventually consistent system replicas can diverge. A "last write" system can be eventually consistent, but a given point can read differently.

Eg: operations

1) Add "AA" to end of string 2) Split string in middle

Replicas R1 and R2 both have the string "ZZZZ"

If R1 sees operations (1) then (2) it will get "ZZZZAA", then "ZZZ", "ZAA"

If R2 sees (2) then (1) it will get:

"ZZ", "ZZ", then "ZZAA", "ZZ".

Strong Eventual Consistency doesn't have this problem because the operations have the time vector on them so the replicas know what order to apply them.

▲

josephg 5 days ago | parent | next [-]

I’m not sure I follow. How would this be eventually consistent at all? It looks like the two peers in your example simply have divergent state and will never converge.

	▲	nl 2 days ago \| parent [-]
		Yes, there is a process to reconcile the states. But the point is that there is a point in time where reading from different replicas gives different results. In the CAP theorem consistency is comprised.

▲

aatd86 5 days ago | parent | prev | next [-]

That precludes us from having side effects such as idempotent triggers right?

▲

simiones 5 days ago | parent | prev [-]

You're not describing an eventually consistent system, you're describing a system that diverges. By definition, eventually consistent means that, after some time, all readers across the entire system are guaranteed to find the same values, even if before that time they may see different values.

Any eventually consistent system has to have a strategy for ensuring that all nodes eventually agree on a final value. R1 and R2 need to communicate their respective states, and agree to a single one of them - maybe using timestamps if R2's value is newer, R1 will replace its own value when they communicate), maybe using a quorum (say there is also an R3 which agrees with R1, then R2 will change its value to match the other two), maybe using an explicit priority list (say, R1's value is assumed better than R2's).

	▲	nl 2 days ago \| parent [-]
		Yes. See https://news.ycombinator.com/item?id=45221779

▲

simiones 5 days ago | parent | prev [-]

I think there are a lot of systems that have a separate node syncing feature, where two nodes can receive updates, apply them to their local replica right away, and only communicate them and reconcile with the other backend nodes at a later time.