How does Couchbase XDCR resolve conflicts between two clusters that both accepted writes?

## What XDCR is **Cross Data Center Replication** copies documents from a bucket on one Couchbase cluster to a bucket on another. It is configured on the source and pushes to the target; it reads mutations from the source's **DCP** stream and applies them remotely, keeping checkpoints so a paused or interrupted replication resumes rather than restarting. It replicates *data*, not cluster configuration: bucket settings, GSI index definitions and users must be created on the target yourself. In Couchbase 7.x replications are defined with explicit scope and collection mapping, and filter expressions can restrict which documents flow. The key property for everything below: XDCR is **asynchronous**. The source acknowledges the client's write on its own terms (including durability levels, which are intra-cluster only) and replication happens afterwards, with a queue and a measurable lag. ## Where conflicts come from Unidirectional XDCR to a passive target has no conflicts as long as nothing else writes the target. The moment you set up the reverse direction too — bidirectional replication is literally two unidirectional replications — both clusters accept writes to the same key space. Two clients can update the same document in two regions within the replication lag window, and neither cluster knew about the other's write when it accepted its own. That is a conflict, and it must be resolved identically on both sides or the clusters permanently diverge. ## Mode one: sequence-number (revision-based) This is the default. Every document carries revision metadata that Couchbase maintains: a revision sequence number that increments with each mutation, plus the CAS value, plus expiry and flags. When an incoming XDCR mutation meets an existing local document, the receiving cluster compares this metadata in a fixed precedence order — revision sequence number first, then CAS, then the remaining fields as tie-breakers — and keeps the winner. The important property is that the comparison uses no wall-clock time and produces the same verdict wherever it is evaluated. Practically, the document that has been mutated more times tends to win, which is a reasonable heuristic but is **not** "the newest write wins": a document updated twice in a quiet region beats a single later update in a busy one. ## Mode two: timestamp (last-write-wins) In LWW mode the comparison is on the CAS value, which Couchbase derives from a hybrid logical clock incorporating wall-clock time. The later timestamp wins, which is the intuitive semantic — and it buys that intuition with a hard operational dependency: **the clocks on all nodes in both clusters must be synchronised**, in practice with NTP and active monitoring of drift. If a node's clock runs ahead, the writes it stamps beat genuinely later writes from correctly-clocked nodes, and the newer data is silently thrown away. If a clock jumps backwards, that node's writes can be ignored entirely. Because the mode is baked in at bucket creation and cannot be changed, and because both ends of a replication must agree on it, this is a decision made before a single document exists — a genuinely load-bearing schema-time choice. ## Deletes Deletions replicate as tombstones and participate in conflict resolution like any other mutation. A delete can therefore *lose* to a concurrent update and the document stays alive, or win and remove a concurrent update's data. "I deleted it and it came back" is a real bidirectional-XDCR support case, not a myth. ## Convergence, not merging XDCR never merges two versions field by field. One whole document version wins and the other is discarded. If your application semantics need both sides' changes preserved — a set of items, a running total, a comment list — the model has to make that safe at the document level: split contended state into per-region documents, use append-style keys, or keep the contended write in one region only. Expecting the database to do a semantic merge is the most common design failure here. ## Operational reality What you monitor is replication lag — the backlog of changes not yet sent — because that backlog is your data-loss window if the source region disappears. What you test is the conflict path, deliberately, before production. And what you write down is which documents may be written in more than one region, because that set is where every conflict will come from. ## Interview traps Candidates often assume LWW is the default (it is not), that the mode can be flipped later (it cannot), that XDCR merges documents (it does not), or that a strong local durability level implies the write reached the other cluster (it does not).