Read this post a few days ago. I am trying to articulate my answer properly, mostly from a client-side dev's perspective. Here is my half-baked thoughts: Stric

Read this post a few days ago. I am trying to articulate my answer properly, mostly from a client-side dev's perspective. Here is my half-baked thoughts: Strict-serializability pretty much guarantees that you don't need any extra business logic to resolve logical states you know you won't, but turns out end up with. If your changes go out in-order over the wire, you know it will be go in with that order on the other end, either that end is temporal or spatial away. However, strict-serializability doesn't solve either business logic errors or collaboration issues. If you have wrong transaction wrapping (things should happen in one transaction got split), or you have race condition locally, SS doesn't help on that. SS doesn't solve collaboration issues because the real-time ordering means both of you will end up in the same state, but if naively implemented, that same state may not be what you would expect (you still need to solve conflicts, and how you solve the conflict has to match the user expectation). Then it goes back to what I originally said, for client-side devs, what they are looking for is to not write any extra business logic to handle states they know they won't end up with when their requests to the server went out in order. For many of these business logics, SS is too strong. A combination of serializability and linearizabily, as the author suggested, could be sufficient. It is just hard to articulate what combination that will be for broad spectrum of business applications.