Locks and atomic operations do not work with replicated databases

Locks and Compare-and-Set operations assume that a single up-to-date value is available in the database. But there is no such guarantee when dealing with databases with multi-leader or leaderless replication. Such databases usually allow several writes to happen concurrently and replicate them asynchronously.

Instead, a common approach is to allow Concurrent Writes to create several conflicting versions of a value and use application code or special data structures to resolve and merge these versions after the fact.

In a replicated environment, atomic operations work exceptionally well if they are commutative, i.e., you get the same result even when you apply updates in a different order. For example, incrementing counters or adding an element to a set are commutative.

The database can then take the onus and prevent lost updates across replicas. Riak 2.0 datatypes are an excellent example of this behavior. Riak automatically merges updates in such a way that no updates are lost. Most other databases simply allow the last write to win, though losing interim updates to the data structure.