Conflict-Free Replicated Data Types (CRDTs) in Multi-Region Databases

State-based and operation-based families

State-based CRDTs ship the whole state and merge with a join function that is commutative, associative, and idempotent. They tolerate duplicate and out-of-order delivery, which makes them forgiving over unreliable links, but the payloads grow.

Operation-based CRDTs ship operations and require exactly-once, causally ordered delivery. Payloads stay small; the messaging layer takes on the burden. Delta-state variants sit between the two and are what most production systems eventually adopt.

Choosing the right type for the data

Most real workloads need only a handful of well-understood types, applied to the fields where concurrent writes actually happen.

• G-Counter and PN-Counter for metrics, quotas, and inventory deltas
• OR-Set for tags, memberships, and feature assignments
• LWW-Register for last-writer-wins fields where loss is acceptable
• RGA or similar sequence types for collaborative text

The costs nobody budgets for

CRDTs carry metadata. Tombstones from removals accumulate, vector clocks grow with the number of replicas, and garbage collection requires knowing that every replica has observed a change — which is itself a coordination problem. Teams that adopt CRDTs without a retention strategy discover the cost eighteen months in, when metadata exceeds the data.

Read performance also changes shape: merging on read is cheap for counters and expensive for large sets, so the access pattern should inform the choice as much as the write pattern.

Hybrid architectures win in practice

The strongest multi-region designs apply CRDTs selectively. Balances, reservations, and anything requiring an invariant across records stay under consensus in a single write region. Presence, preferences, counters, and collaborative documents move to CRDTs and become available under partition. The partitioning of the schema by consistency requirement is the actual design work.