The FailbackKafka · hard · ~16 minTwo weeks ago a regional outage forced the payments-ledger consumer group to fail over from cluster A to cluster B (MirrorMaker 2 replicates both directions). Region A has been healthy for days, and compliance wants the workload back on its home cluster.An engineer proposes: *"Just copy the committed offsets from B to A and restart the group there."*That proposal loses data or replays weeks — your job is to explain why, compute the correct resume point, and write the failback runbook.Evidence

Offsets

Config

Logs

Checkpoints

Why is 'copy the committed offsets from B to A' fundamentally wrong — not just off by a bit?

Using MM2's offset-sync checkpoint (B 1,200,000 ↔ A 912,000) and the group's committed offset on B (1,250,000), compute the translated resume offset on A: translated = committed − (sync_upstream − sync_downstream).

The translated offset trails A's log end and the checkpoint is ~40s stale. What's the correct resume policy?

Write the failback runbook: sequencing, verification gates, and the failure modes you're defending against.