Breaking the Loop: Mastering Redis Multi‑IDC Bidirectional Sync and Conflict Resolution

1. Cycle Break – Breaking the Infinite Replication Loop

When three Redis instances (A↔B↔C) form a bidirectional replication topology, a client write (SET KEY VAL) can circulate endlessly, causing network storms and data inconsistency.

Network storm

Data inconsistency

To stop the loop, the system tags each client request with a flag in the Redis client object, allowing the server to filter out redundant messages and only forward client‑originated writes to peer masters.

2. Last Write Wins & Vector Clock – Simple Yet Complex Conflict Handling

When two replicas concurrently set the same key to different values (e.g., CAT vs DOG), the naive "Last Write Wins" (LWW) rule picks the later write based on wall‑clock timestamps.

LWW fails when clocks are skewed across data centers. Introducing a logical Vector Clock records the causal history of each operation, enabling deterministic conflict resolution independent of physical time.

Amazon DynamoDB builds on this idea with a "Version Clock" derived from vector clocks.

3. Tombstone – Logical Deletion to Preserve Comparison Objects

When a delete operation arrives on one replica while another replica processes a set, the deleted key disappears, leaving no object to compare. A tombstone records a logical delete instead of physically removing the key, allowing later operations to be reconciled.

4. Garbage Collection – Managing Tombstone Growth

Accumulated tombstones consume memory and can eventually crash the system. Traditional GC techniques such as "GC Root" and "Reference Counting" each have trade‑offs.

Our implementation adopts a reference‑count‑like approach: once all peer masters have acknowledged a tombstone, the object is permanently removed.

5. Expire – Consistency of TTL Across Replicas

Redis supports active and passive expiration strategies. In a bidirectional sync scenario, differing TTLs do not affect the consistency of the actual data, only the timing of deletion.

When a key expires on one side, a delete command is propagated to the peer, keeping the visible data consistent.

We experimented with enforcing identical TTLs across replicas, but the extra metadata doubled memory usage, so the final design leaves TTLs independent.