The threats haven't changed. Your exposure has.

Disaster recovery is about recovering IT assets after a major disruption. The threat categories are familiar: ransomware and targeted attacks, accidental deletions, infrastructure failures, third-party outages, and the occasional act of nature.

What's changed is the blast radius. In an event-driven system, a single bad message or a misconfigured retention policy doesn't stay local. It propagates. Fast.

That's the part most DR strategies miss.

‍

RTO and RPO are business questions, not technical ones

Two numbers drive every architectural DR decision.

RPO (Recovery Point Objective) is how much data loss the business can actually absorb. Not "what feels reasonable" but "at what point does this become a survival issue?"

RTO (Recovery Time Objective) is how long the system can be down before the damage becomes irreversible.

The mistake we see most often is engineers pick a number without translating it into business impact. A 4-hour RTO sounds acceptable until you realize it means half a day of orders, transactions, or sensor readings gone. Always anchor these numbers to what the business would actually feel.

‍

Four patterns, four very different risk profiles

There's no universal answer for DR in Kafka environments. Each pattern protects against different failure types, and each comes with trade-offs that matter.

‍

Basic cluster (in-region replication)

Kafka's built-in replication writes data to multiple brokers within a single region. If a broker fails, leader election handles it automatically. RPO and RTO are near-zero for hardware failures.

The problem: if the whole region goes down, or if a bad write replicates across brokers before anyone notices, you're stuck. This pattern handles isolated infrastructure failures well and nothing else.

‍

Active-passive (mirroring)

A tool like MirrorMaker 2 continuously replicates data from a primary cluster to a standby in a different region. When the primary fails, you switch traffic to the standby.

The catch is replication lag. Because mirroring is asynchronous, there's always a window of data that hasn't made it across yet. Your RPO is measured in seconds to minutes under normal conditions. Your RTO, though, is harder to predict. Getting services back online means redirecting traffic, updating DNS, and re-aligning consumer offsets. That process can take hours. Sometimes longer, depending on the complexity of your consumer topology.

Data is protected. Recovery isn't automatic.

‍

Active-active (bidirectional sync)

Both clusters serve live traffic simultaneously and sync to each other. If one site goes down, all traffic routes to the other. RPO and RTO are both near-zero.

The operational cost is real. You need solid conflict resolution logic, governance to prevent data loops, and ongoing coordination across both sites. This is the right answer when downtime is genuinely intolerable. It's overkill when it isn't.

‍

Stretch cluster (synchronous replication)

A single Kafka cluster stretched across three availability zones, with synchronous replication. A message isn't acknowledged until it's confirmed written in at least two zones. If one zone drops, the cluster keeps running without a failover event.

RPO is zero. RTO is near-zero. The cluster doesn't "know" it's in a disaster.

The requirement: low-latency network connectivity between zones. Without the right networking infrastructure, synchronous replication introduces too much write latency to be practical.

‍

The gap none of these patterns fully close

Infrastructure resilience and data integrity are different problems.

All four patterns above protect against site failures. None of them fully protect against data corruption or accidental deletion. If a bad message gets written, it replicates. If a retention policy gets misconfigured, the damage spreads before anyone can stop it.

This is where a decoupled backup layer becomes relevant. An off-cluster backup that captures the event stream independently of the operational cluster won't replicate corruption. A fat-finger incident on the main cluster doesn't touch it. If operational systems are compromised, the backup remains intact.

For organizations running Kafka-compatible event hubs at scale, this kind of backup capability turns near-zero RPO from a theoretical target into something operationally achievable.

‍

DR as a platform responsibility

The conclusion from all of this: DR in event-driven architectures is too complex to leave to individual engineering teams.

Each team managing their own backup strategy, their own failover logic, their own offset alignment process, doesn't scale. The complexity compounds with every new consumer group and every new cluster.

The better model is DR as a platform commodity. A specialized platform team owns the recovery guarantees and makes them available as a service. Engineering teams get the RTO and RPO they need without having to build and maintain the machinery themselves.

Backup, restore, environment cloning, cluster migration: these should be self-service operations backed by a platform, not recurring engineering projects.

‍

Bryan presented this topic at the EDA Community Meetup. Kannika provides backup, restore, and data mobility tooling purpose-built for Apache Kafka and Kafka-compatible event hubs.