Inferensys

Glossary

Kafka Geo-Replication

A feature in Apache Kafka that asynchronously copies topic data between clusters in different geographic regions, enabling disaster recovery while respecting data residency rules.
Data engineer managing feature store on laptop, feature definitions visible, casual data engineering session.
DISASTER RECOVERY & DATA RESIDENCY

What is Kafka Geo-Replication?

A feature in Apache Kafka that asynchronously copies topic data between clusters in different geographic regions, enabling disaster recovery while respecting data residency rules.

Kafka Geo-Replication is the process of asynchronously mirroring message streams between independent Apache Kafka clusters located in distinct geographic regions. Using the MirrorMaker 2.0 framework, it copies topic data, consumer group offsets, and metadata across data centers, ensuring a secondary cluster maintains a near-real-time replica for disaster recovery and failover scenarios.

This mechanism is critical for enforcing data residency and geofenced data pipelines, as it allows architects to selectively replicate specific topics while preventing data from crossing unauthorized jurisdictional boundaries. By configuring allow-lists and topic renaming policies, organizations can maintain a globally consistent namespace while guaranteeing that sensitive records remain physically stored within their legally mandated sovereign cloud region.

CROSS-DATACENTER MIRRORING

Key Features of Kafka Geo-Replication

Kafka geo-replication leverages MirrorMaker 2.0 to asynchronously copy topic data between clusters in distinct geographic regions, enabling disaster recovery and operational continuity while strictly enforcing data residency rules.

01

Asynchronous Offset Translation

MirrorMaker 2.0 automatically translates consumer group offsets between source and target clusters using an offset translation layer. This ensures that if a failover occurs, applications can resume processing from the correct position without duplication or data loss. The translation is stored in a dedicated internal topic (mm2-offset-syncs) within the target cluster, maintaining a precise mapping of source offsets to replicated offsets.

02

Topic Topology Preservation

The replication engine preserves the full topic topology by automatically detecting new partitions and topics in the source cluster and creating corresponding mirrored entities in the target. MirrorMaker 2.0 uses a naming convention (source-cluster.topic-name) to prevent namespace collisions when replicating from multiple source clusters into a single aggregate target, ensuring a clean, conflict-free topology.

03

Cyclic Replication Prevention

To prevent infinite data loops in active-active architectures, MirrorMaker 2.0 employs a provenance header mechanism. Each replicated record is tagged with the identity of the originating cluster. When a consumer in a remote cluster encounters a record with its own cluster's provenance, it discards the record, effectively breaking the cycle and maintaining data integrity across bidirectional replication flows.

04

Geofenced Replication Filtering

MirrorMaker 2.0 supports a filtering API (RecordFilterStrategy) that allows operators to programmatically exclude specific records or entire topics from replication based on custom logic. This is critical for data residency compliance, as it enables the selective replication of only non-sensitive data across jurisdictional boundaries, ensuring that protected records never leave their designated geographic zone.

05

Lag Monitoring and SLAs

Geo-replication introduces a measurable replication lag, defined as the time delta between a record's production in the source cluster and its availability in the target. MirrorMaker 2.0 exposes this lag as a JMX metric (replication-latency-ms), allowing operations teams to define and monitor strict Recovery Point Objective (RPO) SLAs. Typical cross-continental lag ranges from sub-second to several seconds, depending on network bandwidth and throughput.

06

Active-Passive and Active-Active Topologies

Kafka geo-replication supports two primary deployment topologies. Active-Passive replicates from a primary to a standby cluster for disaster recovery, with failover triggered manually. Active-Active allows bidirectional replication between two or more clusters, enabling local reads and writes in each region. The active-active model requires careful conflict resolution and is typically used for globally distributed applications with eventual consistency guarantees.

KAFKA GEO-REPLICATION

Frequently Asked Questions

Clear, technically precise answers to the most common questions about Apache Kafka's cross-datacenter replication mechanisms, designed for data engineers and regulatory compliance architects.

Kafka Geo-Replication is the process of asynchronously copying message streams between independent Apache Kafka clusters located in distinct geographic regions. It works by deploying a dedicated replication tool—most commonly MirrorMaker 2, built on the Kafka Connect framework—that consumes records from a source cluster's topics and publishes them to identically named topics in a target cluster. Unlike intra-cluster replication, which synchronously copies partitions for fault tolerance, geo-replication operates at the topic metadata level, preserving offsets, partitioning schemes, and message headers across WAN links. The replication is continuous and configurable, allowing you to define allowlists, denylists, and topic renaming rules. This architecture ensures that each regional cluster remains an independent, fully functional Kafka deployment while maintaining a near-real-time copy of critical data in a secondary jurisdiction, enabling disaster recovery and data residency compliance without creating a single global cluster that spans high-latency links.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.