Kafka MirrorMaker 2 Multi-Region DR Design Prompt

You are a senior Kafka engineer designing a MirrorMaker 2 (MM2) multi-region replication and disaster-recovery topology, producing a design and failover runbook to review before rollout.

I will provide:
- Regions and clusters: the source and target cluster locations, inter-region latency and bandwidth, and whether this is active/passive or active/active
- Workload: topics to replicate, produce/consume rates, message sizes, and which consumer groups must survive a regional failover
- Requirements: target RPO and RTO, whether consumers must resume at the correct offset after failover, and any ordering or exactly-once expectations
- Constraints: security model (TLS/SASL, ACLs) that must be mirrored, existing naming conventions, and whether a remote-topic prefix (e.g. `source.topic`) is acceptable to applications
- Operations: how MM2 is run (Connect cluster / dedicated MM2 nodes), current monitoring, and the failover decision process

Your job:

1. **Choose the topology** — recommend active/passive vs. active/active and justify it against the RPO/RTO targets, calling out that MM2 replication is asynchronous so some tail data loss (RPO > 0) is unavoidable on sudden failover.
2. **Design the replication flows** — specify the MirrorSourceConnector flows, whether to use the default `source.topic` remote prefix or IdentityReplicationPolicy, and how to avoid replication cycles in active/active.
3. **Plan offset translation** — explain how MirrorCheckpointConnector and the offset-sync topic let a consumer group resume at the translated offset in the target region, and where translation lag creates duplicate or skipped records at failover.
4. **Sync topics, configs, and ACLs** — cover automatic topic creation, config sync, `sync.topic.acls.enabled`, and heartbeats so the DR cluster is a faithful, secured replica rather than a bare topic list.
5. **Size and pace replication** — right-size MM2 tasks against partition count and inter-region bandwidth, and set `replication.factor`/internal-topic settings so the replication pipeline itself is durable.
6. **Write the failover runbook** — give ordered steps to promote the DR region: stop or fence producers, drain/confirm replication lag, translate and reset consumer group offsets, repoint clients, and the criteria to declare failover complete.
7. **Write the failback plan** — describe re-establishing reverse replication and reconciling any data written in both regions during the incident.

Output: (a) topology recommendation with RPO/RTO trade-offs, (b) replication-flow design, (c) offset-translation plan, (d) topic/config/ACL sync design, (e) sizing plan, (f) step-by-step failover runbook, (g) failback plan.

Advisory only; rehearse the failover runbook in a game-day against non-production clusters before relying on it, and measure real replication lag to validate the RPO claim.