You're designing active/passive disaster recovery across two regions with Cluster Linking. Walk through the topology, failover, fail-back, and the key constraints/trade-offs you must account for.

## Goal **Active/passive DR**: one region serves traffic (active), the other stands ready (passive). If the active region fails, you cut over to the passive region with minimal data loss and downtime. ## Topology - **Region A (active)**: receives all producer writes; consumers run here. - **Region B (passive)**: a **cluster link** created in B pulls A's topics into **read-only mirror topics**. Enable: - **consumer offset sync** (`consumer.offset.sync.enable` + group filters) so B knows where each group is, - **ACL sync** (`acl.sync.enable` + filters) so authz is ready, - optionally **auto-create** so new topics in A appear in B. - Because mirroring is **offset-preserving**, B is a faithful, position-accurate copy. ## Failover (A → B) 1. Decide promote vs failover: - **A still reachable** (e.g., planned drill or partial issue) → **promote**: drains mirror lag → **RPO = 0**. - **A is down** → **failover**: immediate writable cutover, **un-replicated tail may be lost** (nonzero RPO). 2. The mirror topics in B become writable (STOPPED state). 3. **Repoint clients**: producers/consumers change `bootstrap.servers` to B. Consumers resume at the **synced offsets** (subject to a small sync lag) with their ACLs already present. 4. There is **no automatic failover** — you (or your automation) execute this runbook. ## Fail-back (B → A) This is where teams get burned. After failover, B has accepted **new writes** that A never saw, so A is now *stale and divergent*. You cannot simply re-enable the old A→B link. Steps: 1. Once A is healthy, create a **reverse link in A** that mirrors B's topics into A (read-only). 2. Let it **catch up** (drain lag) — this can move a lot of data if B ran for a while. 3. During a maintenance window, **promote** the topics back in A and **repoint clients** to A. 4. Re-establish the original A→B link for steady state. ## Key constraints & trade-offs - **Unidirectional links**: a link mirrors one direction. True **active-active** with the same topic written on both sides isn't supported by a single link (offset collisions); you'd use separate topics/prefixes per region. - **No auto-failover / no split-brain protection built in**: you must avoid both regions accepting writes to the same logical topic simultaneously. - **Periodic sync**: offset/ACL sync is not real-time, so there's a small **position RPO** even when data is fully replicated. - **Schema Registry**: schemas are **not** carried by the topic mirror; replicate Schema Registry separately (e.g., Schema Linking) or you'll fail to deserialize after cutover. - **Transactions/EOS**: producer transactional state and `__transaction_state` don't trivially translate; design for at-least-once on failover unless you've validated EOS behavior. - **Networking/security**: cross-region reachability (PrivateLink/peering), credential rotation, and quota/throughput on the link must be sized for the full backlog after an outage. - **Confluent-only & cost**: Cluster Linking is a Confluent feature; cross-region egress and storage cost money. ## RPO/RTO framing - **RPO**: ~0 for promote; the un-replicated tail + position-sync lag for failover. - **RTO**: dominated by detection + the manual/automated cutover + client repointing. ## Bottom line Cluster Linking gives you a low-overhead, offset-accurate passive replica, but DR correctness lives in the **runbook**: promote-vs-failover decisioning, fail-back via a reverse link, schema replication, and split-brain avoidance. Drill it.