It’s probably more difficult to solve the problem of identifying which messages become inconsequential (given the unknown rules that will operate on them when replayed against the server) than to just deal with each concurrency/business rules conflict on the server as usual.

However, the solution of queueing up messages or business actions on a disconnected client and resolving the concurrency issues in bus. logic as they are “played” upon reconnection still leaves us with a serious problem that you didn’t explore. If we have several messages in the queue whereby one of the later messages makes one of the earlier messages irrelevant (ex: I changed my address 2x) and one of the inconsequential messages causes a concurrency conflict to occur, we would potentially be asking the user to resolve an issue for an intermediate action that is no longer relevant to them and has probably left their mental model.

The only solution I can see here that might apply is to optimize the queue as messages get added or as the queue is played back. This brings us back very much into into ‘not straight forward land’. Any thoughts on this?