State-Based vs. Operation-Based CRDTs

Two Flavors of the Same Idea

All CRDTs come in two implementation styles. Understanding the difference matters when you're choosing or implementing one.

State-Based CRDTs (CvRDTs — Convergent):
Replicas periodically send their entire current state to other replicas. The receiver merges the incoming state with its own using a merge function.

Replica A state: { A: 5, B: 0 }
Replica B state: { A: 0, B: 3 }

A sends full state to B.
B merges: { A: max(5,0), B: max(0,3) } = { A: 5, B: 3 }

• Pro: Simple to reason about. Any message can be replayed safely (idempotent by design).
• Con: Sending the full state is expensive for large data structures. A document with 10,000 elements sends all 10,000 elements on every sync.

Operation-Based CRDTs (CmRDTs — Commutative):
Replicas send only the operations (deltas) to other replicas. The receiver applies the operation directly.

Replica A: "Increment lane A by 1"
Replica B receives and applies: A's lane goes from 0 to 1

• Pro: Bandwidth-efficient. Only the change is transmitted.
• Con: Requires the messaging layer to guarantee exactly-once delivery and causal ordering. If a message is lost or duplicated, the state diverges. This puts more burden on the infrastructure.

Delta-State CRDTs are a hybrid: they send only the delta (the changed portion of the state) rather than the full state, combining the simplicity of state-based CRDTs with the efficiency of operation-based ones. This is the approach used by most modern production CRDT libraries.

Key Point: In practice, most production systems use delta-state CRDTs or operation-based CRDTs with a reliable message bus (like Kafka with exactly-once semantics). The choice depends on your network reliability guarantees and the size of your state.