Strings and bitfields in Active-Active databases

Active-Active databases support both strings and bitfields.

Changes to both of these data structures will be replicated across Active-Active member databases.

Replication semantics

Except in the case of string counters (see below), both strings and bitfields are replicated using a “last write wins” approach. The reason for this is that strings and bitfields are effectively binary objects. So, unlike with lists, sets, and hashes, the conflict resolution semantics of a given operation on a string or bitfield are undefined.

How “last write wins” works

A wall-clock timestamp (OS time) is stored in the metadata of every string and bitfield operation. If the replication syncer cannot determine the order of operations, the value with the latest timestamp wins. This is the only case with Active-Active databases where OS time is used to resolve a conflict.

Here’s an example where an update happening to the same key at a later time (t2) wins over the update at t1.

String counter support

When you’re using a string as counter (for instance, with the INCR or INCRBY commands), then conflicts will be resolved semantically.

On conflicting writes, counters accumulate the total counter operations across all member Active-Active databases in each sync.

Here’s an example of how counter values works when synced between two member Active-Active databases. With each sync, the counter value accumulates the private increment and decrements of each site and maintain an accurate counter across concurrent writes.