[taeric]

Alternatively, don't require strong consistency everywhere. Instead, make sure to have it places it makes sense, and always reason about it.

I view this as a generalization of optimistic locking on source control. I don't envy my past self for having to checkout code with a lock that I was going to change it.

[sriram_malhar]

Are you saying that optimistic locking isn't strongly consistent? If so, that's not quite correct. When the locking is optimistic, a serialisable transaction would abort if found conflicting with another transaction.

[taeric]

I'm saying that requiring strong consistency is like requiring pessimistic locking in an org. In some ways, it sounds easier and seems to have better guarantees. In practice, it is more work and slows you down.

[sriram_malhar]

Strong consistency has strong guarantees, not just 'seems' to have -- hence the name.

In practice, strong consistency is less work for the client in many many (most?) cases. If concurrent clients can update the same key concurrently in several places, then the onus is on the client to somehow merge the differing versions at some point. There are few good options to do so correctly and efficiently. Let's consider the options.

a) Timestamps and last writer wins. Every version is time-stamped, and while merging, the latest timestamped version wins out. This is error-prone; a misconfigured clock can cause havoc.

b) Version-vectors: Allow you to track the causal history of different versions, but you still have the problem that if two versions are indeed concurrent, the client has to have code to merge them automatically -- experience with the Bayou system showed that this isn't easy. Your source-code example is in this category; recall how Git cannot always automatically merge conflicting changes ... the developer has to step in for manual changes.

3) Lattices. If you have the good fortune to have your data exhibit lattice properties (like CRDTs), then automatic merging is easy and elegant. However, you still don't get compositionality.

For a vast majority of the examples in recent history that have made a case for eventual consistency, subsequent examples have shown how to achieve strong consistency and still maintain respectable performance, as the subject of this thread indicates. Google Spanner and CockroachDb are linearizable, the strongest possible consistency, and are geo-replicated and unburdened by traditional lock or 2PC issues.

[taeric]

Yeah, I'm not saying to completely abandon it. However, folks are well served learning that idempotency is your friend. Not always achievable, to be sure. However, even ec2 lets you launch instances with an idempotency key.

So, where I said "seems" to have. Take that more as these "seem to be required guarantees." In practice, they are not required and you need to have plans for them failing, at any rate. Rather than build up a system so that fluke failures are painful, make one that is constantly checking for failures and doing incremental work.

But, above all, my point was to reason about it. Not to take anything as written in stone.

[irfansharif]

CockroachDB’s external consistency guarantee is by default only serializability. We do provide a limited form of linearizability however, providing ordering for any observer or chain of observers[1].

[1]: https://github.com/cockroachdb/cockroach/blob/master/docs/de...