[qt_scientist]

Good discussion of an (indeed) epic article. Reading the other comments here, I would like to stress the complexity of allowing concurrent updates of the same object on distributed machines.

And I totally share the hopes for the current eventual consistency monopoly to perish. Some use cases should use strong consistency. You see people build stuff like this https://github.com/Netflix/s3mper to "fix" eventual consistency...awkward

[nawitus]

Cconcurrent update of the same object is actually an extremely common real-life use case. You need to handle the arising conflicts anyway, so you might as well get the benefits of eventual consistency. If you don't have concurrent updates, then you don't have a distributed system. But that doesn't model the real world anymore. The state of the object is already distributed to multiple computers (e.g. mobile clients), and the database system needs to handle that.

You can, of course, handle the concurrency on the application level, but the question is, why bother? The database can help with managing that.

[grogers]

The whole industry has been slowly trending away from eventual consistency. Google proved with spanner that it is possible to do linearizable transactions at mega scale. Even Amazon's DynamoDB offers strong consistency for individual rows.

Nobody wants to throw data away on concurrent writes, and CRDTs or application specific merge functions are complicated.