> your storage system is just a dumb storage system that simply returns the object version with the highest clock. what makes it linearizable to an outside obse

> your storage system is just a dumb storage system that simply returns the object version with the highest clock. what makes it linearizable to an outside observer is that the system generating the lock ids is itself linearizable. I don't think you understand Martin motivations. He says that the system has to reject the write with a lower ID, in order to protect from concurrent accesses, and to do so in a way that the client attempting a stale write is notified. If you mount an eventually consistent system returning the object with higher version, there is nothing of linearizable about it. If the shared resource is a list of names, one client will try to add "Hellen" with version 8, one will try to add "Josh" with version 9. Only one name will end in the list in your schema, and the client adding "Josh" will not even know that the write failed. So the goal is, when race conditions happen, to avoid them in some way. While I believe that when you use a distributed lock the problem is very often that you don't have other controls over the shared resource, if you really need to do that, a random token is equivalent: using CAS you can reject one of the writes if two clients are writing at the same time. Note also that when it happens that, because of delays, the clients are accessing concurrently, the lock ID has little to do with the order in which the operations were indented to happen. Back to "add name to a list" problem: T0: Client A receives new name to add from web. T0: Client B is idle T1: Client A is experiencing pauses. T1: Client B receives new name to add from web. T2: Client A is experiencing pauses. T2: Client B receives a lock with ID 1 T3: Client A receives a lock with ID 2 ... So the client that received the name before, can do the operation after, or you can have delays in any other part of the system.