> For the complete documentation index, see [llms.txt](https://docs.lenses.io/latest/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lenses.io/latest/k2k/use-cases.md).

# Use cases

Main scenarios K2K is built for.

When operating across more than one Kafka cluster, organizations need data, schemas, and consumer positions to stay aligned between the source Kafka cluster and the target Kafka cluster. K2K provides these capabilities, allowing a seamless transition between Kafka clusters whether the goal is resilience, migration, or feeding downstream environments.

This page describes the main scenarios K2K is built for. For step-by-step procedures, see [Runbooks](/latest/k2k/runbooks.md). For configuration, see [Minimal Configuration](/latest/k2k/minimal-configuration.md) and [Configuration Reference](/latest/k2k/configuration-reference.md).

## Disaster recovery

When planning for disaster recovery, organizations require a standby cluster that holds a current copy of production data, the schemas those records depend on, and valid consumer positions on the target Kafka cluster before a failover occurs.

K2K replicates selected topics to the standby on an ongoing basis, keeps schemas available on a target Schema Registry, and translates consumer group offsets from the source Kafka cluster to the target Kafka cluster.

When operations initiate a failover, applications can switch to the standby cluster and resume without reprocessing from the beginning. End users are unaware of K2K; operators monitor replication lag and direct consumers to the target Kafka cluster when ready.

See the [Disaster recovery runbook](/latest/k2k/runbooks/disaster-recovery.md).

## Cluster migration

When replacing a Kafka cluster (for example when moving cloud provider, region, or datacenter), organizations require the source Kafka cluster and the target Kafka cluster to stay in sync while applications are moved over gradually, with schemas and consumer positions carried across to the new environment.

K2K replicates selected topics from the old cluster to the new one while both remain in service. It translates consumer group positions as each application switches and replicates schemas to a target Schema Registry where needed.

Once all workloads run on the target Kafka cluster, operators stop K2K and decommission the source Kafka cluster.

See the [Cluster migration runbook](/latest/k2k/runbooks/cluster-migration.md).

## Test, staging, and analytics environments

When feeding test, staging, or analytics clusters from production, organizations require only the relevant topics to be copied, not the entire cluster, so downstream workloads can run against realistic data without touching production.

K2K copies the subset defined in the pipeline, by topic name or by regex pattern (for example `orders.*`).

K2K does not copy topics outside the pipeline configuration.

## Active/active and bidirectional replication

When both Kafka clusters must produce and consume data simultaneously, K2K can replicate in both directions without records cycling between clusters. Each direction runs as a separate pipeline with loop prevention enabled.

See [Bidirectional replication](/latest/k2k/configuration-reference/bidirectional-replication.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.lenses.io/latest/k2k/use-cases.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.