As is the issue with an ambiguous response, finding out whether we've updated the value or not is in some way unknowable. In the case of a single client, we can use CAS values to determine whether or not the value has been modified by the ambiguous operation (but not if it may still be in the future - in the case of failed over / slow nodes etc.), but once multiple clients are allowed to edit the value, it becomes impossible(? suggestions welcome) to tell whether we modified the value or another client did (eg. if both clients GET -> x and SET x+10). Solutions for this issue fall into more complex application logic such as pessimistic locking, or breaking down the stored value such that it can be edited idempotently (eg instead of a single balance, keep an array of transaction history that is appended to). I'll write samples for both of these examples, and any others that are suggested.