Redis Enterprise offers active-active geo-replication, where several regions accept writes to the same dataset simultaneously. What mechanism makes concurrent writes converge without a coordinator, and which guarantees do you NOT get from it?

## The problem being solved A globally distributed application wants local write latency in every region. The classical alternatives are a single primary (remote regions pay a round trip and lose write availability when the primary is unreachable) or consensus (every write pays a quorum round trip). Active-active takes a third route: **accept writes everywhere, replicate asynchronously, and make conflicts impossible to get wrong by construction**. "By construction" means conflict-free replicated data types: data types whose merge function is commutative, associative and idempotent, so replicas that have seen the same set of updates — in any order, with duplicates — reach the same state. No coordinator, no locks, no quorum. The cost is that the merge rule, not the application, decides what "concurrent" means, and the rule differs per type. ## How each Redis type behaves **Counters.** The naive replication of "the new value is 7" loses updates when two regions increment concurrently. Instead, increments replicate as **operations**: region A ships +1, region B ships +1, and both converge to +2 over the original value. This applies to INCR/INCRBY on strings, HINCRBY on hash fields, and sorted-set score increments. It is the strongest argument for active-active: distributed counting that actually adds up. **Collections (sets, hashes, sorted sets).** Elements are tracked with observed-remove semantics. A delete removes only the element instances the deleting replica had actually observed. So if region A adds `x` while region B deletes the `x` it had seen, the add survives — "add wins". This is deliberate: losing a newly created element is usually worse than keeping one that someone tried to remove. **Plain string values.** `SET k v` replaces an opaque blob. There is no meaningful merge of two different blobs, so the system resolves **last-write-wins** using the timing information it maintains across regions. One writer's value simply disappears. This is the single most important thing to state in an interview: active-active does *not* make concurrent overwrite of the same string safe — it makes it *deterministic*, which is not the same as *correct for your business*. **Expiry and deletes.** TTLs converge by keeping the longer expiry so a key does not vanish from under a region that just extended it. Deletes propagate as tombstones, which linger until garbage collection — part of why a CRDB uses noticeably more memory per key than a plain database. ## What the model does not give you - **No linearizability or global order.** Two regions can transiently disagree; there is no single ordering of operations that every observer sees. - **No read-your-writes across regions.** A write in Frankfurt is not visible in Virginia until replication delivers it. - **No cross-region atomicity.** MULTI/EXEC executes locally; WATCH-based optimistic concurrency only detects changes made in the local instance, so it cannot protect against a concurrent remote write. Scripts likewise run locally and must be written so their effects merge sensibly. - **No zero-RPO failover.** Replication is asynchronous, so an acknowledged local write can be lost if the region is destroyed before the write ships. Durability is per-region. - **No escape from application semantics.** "Deduct one from the balance" merges beautifully as a counter; "set the balance to 40" does not. Modelling matters more here than in any single-region deployment. ## Operational consequences **Cost.** Every region stores the entire dataset and pays cross-region bandwidth for every write, so a five-region CRDB is roughly five copies of the data plus a full write fan-out. **Metadata overhead.** CRDT bookkeeping and tombstones increase memory per key relative to an equivalent non-CRDB, and garbage collection of tombstones is a background cost. **Command restrictions.** Some commands behave differently or are restricted in a CRDB precisely because they cannot be merged meaningfully; check the supported-command matrix before assuming parity with a single-region database. **Session affinity helps a lot.** Pinning a user to one region for the duration of a session sidesteps most read-your-writes surprises without giving up the multi-region write path. ## Choosing it Active-active is right when you genuinely need local writes in multiple regions and your data model is dominated by mergeable operations — counters, tallies, set membership, presence, feature-flag exposure, session data with region affinity, shopping-cart style add/remove. It is the wrong tool when the truth of a value depends on reading it first and writing back a derived value across regions; that requires coordination, and no CRDT will supply it. The professional answer names both the mechanism and that boundary.