[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.