For a two-region Couchbase deployment, when would you choose bidirectional XDCR over one stretched cluster?

## Frame the decision correctly This is not "which is faster". It is a question about failure domains, write latency, and who is allowed to write what. Answer it in that order. ## Why not stretch a single cluster A Couchbase cluster is a tightly coupled unit. Nodes exchange heartbeats and a shared cluster map; replicas are fed by DCP from actives; durable writes wait on cross-node acknowledgements; rebalance streams large volumes between nodes. Every one of those assumes low, stable latency between members. Put half the nodes in another region and: durable writes pay a WAN round trip on the critical path; the failure detector sees WAN jitter and either flaps toward auto-failover or must be tuned so slow that real failures go unhandled for minutes; a regional partition splits the cluster's membership rather than isolating a self-sufficient half; and rebalances push large data volumes over expensive, slow links. Couchbase's own guidance is unambiguous here: multi-region means multiple clusters connected by XDCR, not one cluster with distant nodes. ## What XDCR actually gives you Two clusters, each complete: its own vBucket map, its own replicas, its own failover behaviour, its own rebalances. XDCR streams mutations between them continuously, checkpointed so it survives pauses and restarts. A region can lose nodes, rebalance, or fall over entirely without dragging the other with it. What it does **not** give you is a cross-cluster commit. Durability levels are intra-cluster: `persistToMajority` says nothing about the other region. The exposure is the replication backlog, and it should be an explicit, monitored number — that backlog *is* your RPO when a region is lost abruptly. ## Active-passive or active-active? **Active-passive** — all writes in one region, the other read-only or dormant — has no conflicts at all. It is the right default whenever the business can accept a failover procedure instead of continuous dual writes. The design work is in the promotion runbook and the DNS/routing switch, not in the data model. **Active-active** — both regions accept writes — buys local write latency for users in both regions and instant capacity on the surviving side. It costs you conflicts, and conflicts in Couchbase are resolved by discarding a whole document version, never by merging fields. So active-active is only safe for data whose contention you have designed away. ## The rule that makes active-active work: single writer per document The practical pattern is to keep both regions active while ensuring each *document* has one home. Route a tenant, a user, or a key range to a region and write it only there. The other region serves reads and stands ready to take over. Conflicts then only occur in the seam — the failover window, or a misrouted request — where the deterministic resolution is a safety net rather than the mechanism your correctness depends on. When state is genuinely shared, restructure it: per-region documents aggregated at read time, append-style keys instead of mutating one hot document, or keeping a small strongly-contended slice single-region while everything else is local. ## What I refuse to put behind active-active Anything where losing one of two concurrent updates is a business error and the merge is not expressible as "pick a version": monetary balances and ledgers, inventory decrements against a hard limit, uniqueness claims such as username registration, and sequence or counter allocation. Those either stay single-writer or move to a design that makes the operation idempotent and commutative. Choosing timestamp (LWW) conflict resolution for such data compounds the problem, since it makes correctness depend on NTP discipline across both regions. ## Choose the conflict-resolution mode before the first document The mode is fixed at bucket creation and both ends must match. Sequence-number mode needs no clocks and is the safer default; timestamp mode gives the intuitive "latest wins" semantic but makes clock skew a silent data-loss mechanism. Changing your mind later means a new bucket and a migration, so this belongs in the design review, not in an operations ticket. ## What you must be able to operate Monitor the XDCR backlog per replication and alert on it as an RPO breach, not as a performance metric. Rehearse regional failover including the routing switch and the return of the failed region — the return is where duplicate writers and conflict storms actually appear. Remember that XDCR carries documents only: index definitions, users, and bucket settings must exist on the target before it is useful, and a standby you never queried is a standby you cannot trust. ## How I would answer in one line Two clusters with XDCR, always, for two regions; active-passive unless local write latency in both regions is a stated requirement; active-active only with a documented single-writer routing rule and a named list of data that stays single-region.