Anti-Entropy / Merkle Sync

TechniqueCoordinationSeniorStaffUpdated Nov 10, 2026

Background process that compares replicas using a Merkle tree of data and ships only the differing ranges.

When to Use Anti-Entropy / Merkle Sync

Keeping replicas in sync when read-repair alone won't reach cold data. Catch-up after a node was offline for a long time.

In Practice

Cassandra's nodetool repair builds Merkle trees per range. DynamoDB does similar. Riak and Bitcoin/Ethereum P2P sync use the same Merkle-tree-difference trick.

How Anti-Entropy / Merkle Sync Comes Up in Interviews

Scenario

A Cassandra node was offline for a day and came back. You need to bring it back in sync efficiently: ship only the ranges that actually differ from peers, not the entire dataset. Which mechanism does nodetool repair use?

Anti-entropy builds Merkle trees per range so peers can diff their hashes and ship only the differing leaves. Read repair only fixes data that gets read; long-offline cold data needs the background sweep.

Anti-entropy with Merkle trees lets two replicas compare their entire keyspace by exchanging O(log n) hashes per range and shipping only the differing leaves. Cassandra's nodetool repair builds Merkle trees per token range; DynamoDB does similar; Riak uses 'active anti-entropy.' The same Merkle-tree-difference trick powers Git's pack negotiation, Bitcoin and Ethereum's chain sync, and IPFS's content addressing. Read-repair alone would never reach the cold rows the offline node missed, so anti-entropy is the backstop for true convergence after long outages or full node replacements.