Explain how you'd handle a multi-region Kafka deployment for disaster recovery.

Options: 1) Active/passive with MirrorMaker 2 (a flow such as A->B): the primary cluster takes all traffic, and MirrorMaker 2, which is built on Kafka Connect, consumes from the source cluster and produces to the DR cluster, replicating topics and consumer groups; replicated topics get a source-cluster prefix by default (A.orders). RTO is the time it takes you to repoint applications at the DR cluster; RPO is roughly what has not yet been replicated, so monitor replication latency (the replication-latency-ms metric). 2) Active/active (A->B, B->A): both clusters take writes and MirrorMaker 2 replicates in both directions; the prefix naming prevents replication loops, because a topic whose name already carries a cluster's alias is not replicated back to that cluster. 3) A single cluster stretched across sites is a different design from the separate, linked clusters the geo-replication docs describe. 4) Failover: MirrorMaker 2 emits checkpoints (emit.checkpoints.enabled, default true) with translated consumer group offsets; sync.group.offsets.enabled (default false) writes them to the target's __consumer_offsets for groups with no active consumers there. Translation is approximate, since not every offset can be translated, so plan for some reprocessing; exactly-once is supported for dedicated MirrorMaker clusters since 3.5.0. Monitor lag continuously and rehearse failover regularly.

Expected key concepts: active/passive, active/active, MirrorMaker 2, prefix, replication loops, RPO, RTO, checkpoints, translated consumer group offsets, sync.group.offsets.enabled, failover