Or you design the protocol (or rather, the operations which are applied to the data) so that conflicts can be trivially resolved. In your example you could hav

Or you design the protocol (or rather, the operations which are applied to the data) so that conflicts can be trivially resolved. In your example you could have a single operation, SET, which sets a field at a particular address to the given value. User John sends a list of SET operations, all in the form of 'SET "<item X>.deleted" true' for all items 'X' which he wants to get rid of. Steve sends a list of SET operations in the form of 'SET "<item X>.name" ???', which don't conflict with what John sent. The key point is to have stable addresses (eg. never delete objects so that addresses within it remain valid forever). And a small set of fundamental operations on them where conflicts can automatically be resolved by the computer (you get get by for a long time with just SET, and if you have just SET then conflict resolution is trivial). Note that in that system there is no notion of a 'Delete all users whose names begin with 'A'" operation. That's a very complex operation with very narrow use case. And it requires a lot of logic to handle all the potential conflicts with other such complex operations.