[Cojen]

The definition of "eventually consistent" is somewhat vague in this respect, or at least easily misunderstood. When updates are streamed and applied sequentially, "eventual" is easily determined as the number of messages that the stream is behind. I'd say that this model is "deterministically consistent", because we know at which point the replicas will all agree with each other without having to perform a full comparison.

[rubiquity]

Sequential Consistency is the name for this model. Writes don’t get lost but it is weaker than linearizability because you can read after a commit and not get the latest value but eventually (not the same eventual as eventual consistency) you will. Typically data systems provide this to optimize for read scale out, otherwise all reads have to go to the leader.

In “eventual consistency” you could read the committed value at some time, no value, or another committed value depending on the exact implementation. It’s a much, much weaker consistency model than Sequential Consistency and Session/Causal Consistency is the closest you can even get to sniffing a stricter model.

I had a longer comment about this new page and MongoDB as a whole but I’ll just swallow my words. They know what they’ve done and don’t really care.

[pritambaral]

> Sequential Consistency is the name for this model. Writes don’t get lost but ...

Writes can get lost if the primary dies and the secondary is promoted in the meanwhile.

[rubiquity]

Yes but this is dependent upon the specific replication protocol. Primary-Backup has this problem but Majority Quorums and Chain Replication do not.

[pritambaral]

The parent is talking specifically about 'Sequential Consistency'.

[rubiquity]

My point is that Sequential Consistency isn’t a replication protocol, it’s a consistency model that you can have under various different replication protocols.

[vorpalhex]

> Eventual consistency is a consistency model used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. [1]

That is literally the definition of eventual consistency. How you achieve it doesn't matter to being eventually consistent, just that it is.

[1] - https://en.wikipedia.org/wiki/Eventual_consistency

[Cojen]

This makes me wonder how it's possible how to replicate data without being eventually consistent. I can't transmit data faster than the speed of light. It seems that the definitions here need more clarity, because eventual consistency in the broadest sense applies to everything. Is there a good example of replication consistency which isn't "eventual", but is instead immediate?

[rubiquity]

It’s all about when you acknowledge back to the client, whether you accept writes at a single writer or multiple writers, and whether reads can be served from any node. Most EC systems tend to be multi writer with async replication. This means clients get acks immediately and reads to other nodes for those values can contain various values. The speed of the network doesn’t matter from a theoretical perspective. Network speed only affects potential convergence times. Time is time regardless of the unit of measurement.

See my other comment above for distinguishing between EC and Sequential.

[irjustin]

I don't think the OP is arguing that replicated data is not "eventually consistent" because it is as you say.

OP is arguing the blog post is trying to change the definition of "eventually consistent"... the author is saying the delay between the master and slave is not "eventually consistent"... when, exactly as you say, it is.

[amluto]

SQLite, appropriately configured, is trivially linearizable — everything is protected under one lock on one machine.

[eindiran]

This explains it pretty well: https://www.cs.princeton.edu/courses/archive/spr18/cos518/do...

[Jasper_]

Here's an overly simple, impractically slow, but immediately consistent model for you: for every request from a client, ask all other nodes in the network the same query. If you get 100% consensus, return the answer, otherwise, ask again.