Or you design the protocol (or rather, the operations which are applied to the data) so that conflicts can be trivially resolved.<p>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 &#x27;SET &quot;&lt;item X&gt;.deleted&quot; true&#x27; for all items &#x27;X&#x27; which he wants to get rid of. Steve sends a list of SET operations in the form of &#x27;SET &quot;&lt;item X&gt;.name&quot; ???&#x27;, which don&#x27;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).<p>Note that in that system there is no notion of a &#x27;Delete all users whose names begin with &#x27;A&#x27;&quot; operation. That&#x27;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.