---
title: "Kafka failover and failback with Confluent Cluster Linking"
description: "Switch to the dr mirror, produce O4, switch back. Confluent Cluster Linking reverses the link in place and both Kafka clusters keep identical offsets 0 to 4."
url: https://monedula.dev/kafka-simulator/scenarios/bidirectional-links-failback/
---

# Kafka failover and failback with Confluent Cluster Linking

Scenario 10.2.5 · Bidirectional links and clean failback. Disaster recovery · Advanced · about 5 min · Apache Kafka 4.3.

Cluster Linking is offset-preserving, so you can switch the active cluster over to the mirror and later switch BACK - the link reverses in place and offsets stay consistent end to end, with no reprocess window.

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=10.2.5

## What you start with

Because Cluster Linking copies records at identical offsets, failover can be clean and reversible: promote the mirror to writable (switchover), produce on it, then later promote the original back (switchback). Each switch reverses the link in place, and no offsets are ever remapped.

## Step by step

1. **One cluster link, primary → dr** (t+0.000s): A cluster link mirrors orders from primary into the read-only mirror primary.orders on dr. Cluster Linking is offset-preserving, so the mirror will hold the same records at the same offsets. The prefixed name is a simulator label: Confluent's reverse commands refuse prefixed links, so a reversible mirror is called orders on both sides. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.5&t=0)
2. **Forward mirror (offset-preserving)** (t+0.700s): Three records on orders (primary) are mirrored byte-for-byte into primary.orders (dr) at identical offsets - both at high-watermark 3. primary.orders is a read-only mirror. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.5&t=1)
3. **Switchover: promote + reverse** (t+1.050s): switch_cluster_link promotes primary.orders to writable on dr, DEMOTES orders to a read-only mirror on primary, and reverses the link in place (dr → primary) so it mirrors back into the original orders topic. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.5&t=2)
4. **Produce on the new primary; mirror back** (t+1.500s): A dr-local producer appends O4 to the promoted primary.orders at offset 3. The reversed link mirrors it back into orders on primary at the SAME offset 3 - both at high-watermark 4. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.5&t=3)
5. **Switchback: promote + reverse again** (t+1.750s): switch_cluster_link promotes orders back to writable on primary, demotes primary.orders to a read-only mirror on dr, and reverses the link forward again (primary → dr). [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.5&t=4)
6. **Offsets consistent end to end** (t+2.200s): O5 produced on the restored primary lands at offset 4 and is mirrored forward to primary.orders at the SAME offset 4. Both copies now hold offsets 0..4 identically - no reprocess window, no data loss. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=10.2.5&t=5)

## The takeaway

After a full switchover and switchback both clusters hold the same records at the same offsets - there is no reprocess window and no data loss. Offset preservation is what makes Cluster Linking failover and failback clean and bidirectional.

## Further reading

- [Confluent documentation](https://docs.confluent.io/platform/current/multi-dc-deployments/cluster-linking/index.html)