Streaming

Choose Your Deployment

Before you deploy Redpanda for production, choose the cluster topology that matches the failures you must survive and your recovery objectives: how much data you can afford to lose (recovery point objective, or RPO) and how quickly you must recover (recovery time objective, or RTO). Each topology mitigates a different class of failure, from the loss of a single broker to the loss of an entire region, and makes different trade-offs in latency, license requirements, and operational complexity. This page compares the available topologies along those dimensions and routes you to the right deployment guide.

After reading this page, you will be able to:

  • Compare Redpanda deployment topologies by failure domain, recovery objectives, and operational cost

  • Choose the deployment guide that matches your availability requirements

What you’re protecting against

Use this table to identify the failures you must plan for and the mechanisms that mitigate them:

Failure Impact Mitigation strategy

Broker failure

Loss of function for an individual broker or for any virtual machine (VM) that hosts the broker

Multi-broker deployment

Rack or switch failure

Loss of brokers/VMs hosted within that rack, or loss of connectivity to them

Multi-broker deployment spread across multiple racks or network failure domains

Data center failure

Loss of brokers/VMs hosted within that data center, or loss of connectivity to them

Multi-AZ or replicated deployment

Region failure

Loss of brokers/VMs hosted within that region, or loss of connectivity to them

Geo-stretch (latency dependent), such as a Stretch Cluster on Kubernetes, or replicated deployment

Global, systemic outage (DNS failures, routing failures)

Complete outage for all systems and services impacting customers and staff

Offline backups, replicas in 3rd-party domains

Data loss or corruption (accidental or malicious)

Corrupt or unavailable data that also affects synchronous replicas

Offline backups

Decision dimensions

Weigh the options against these dimensions:

  • Failure domain: The largest unit whose loss you must survive: a broker, a rack, an availability zone (AZ), a region, or an entire Kubernetes cluster.

  • RPO: Synchronous Raft replication within one cluster means zero data loss. Asynchronous replication between clusters means near-real-time copies with some replication lag.

  • Failover: A single cluster fails over automatically through Raft leader election. Independent clusters require a runbook-driven failover, including redirecting clients.

  • Latency: Synchronous replication across distant locations adds produce latency and requires tuning. Asynchronous replication has no distance ceiling.

  • Client semantics: A single cluster keeps one set of offsets. Shadowing preserves offsets on an independent cluster, so consumers can resume after failover.

  • License and complexity: Some topologies require an Enterprise license and more operational investment.

Compare topologies

graph TB subgraph single["Single cluster, multi-AZ: zonal resilience"] direction LR sa["Broker
AZ 1"] <--> sb["Broker
AZ 2"] <--> sc["Broker
AZ 3"] end subgraph stretch["Stretch Cluster: one cluster across Kubernetes clusters"] direction LR subgraph k1["Kubernetes cluster 1"] t1["2 brokers"] end subgraph k2["Kubernetes cluster 2"] t2["2 brokers"] end subgraph k3["Kubernetes cluster 3"] t3["1 broker"] end t1 <-->|"synchronous Raft"| t2 t2 <--> t3 end subgraph shadow["Independent clusters with Shadowing: disaster recovery"] direction LR subgraph src["Source cluster"] p1["Brokers"] end subgraph dst["Shadow cluster"] p2["Brokers"] end p1 -->|"asynchronous shadow link"| p2 end single ~~~ stretch ~~~ shadow
Figure 1. The three topologies at a glance

A single cluster replicates synchronously between brokers, whether those brokers share one Kubernetes cluster (multi-AZ) or span several (Stretch Cluster). Shadowing instead copies data asynchronously between two independent clusters.

Single cluster, multi-AZ Stretch Cluster (one cluster across Kubernetes clusters) Independent clusters with asynchronous replication (Shadowing)

Survives

Loss of one AZ (with three or more AZs)

Loss of one region, data center, or Kubernetes cluster (with three or more)

Loss of an entire region or cluster; also isolates the replica from many data-corruption events

Replication and RPO

Synchronous (Raft), zero data loss

Synchronous (Raft), zero data loss, one set of offsets

Asynchronous, near real time, and offset-preserving, with an RPO greater than zero

Failover

Automatic

Automatic

Runbook-driven: fail over shadow topics, then redirect clients

Latency requirement

Low inter-AZ latency. Produce round trips stay in the single-digit milliseconds.

Low inter-cluster latency (under 50 ms recommended, which in practice means same-continent locations). Produce pays a cross-location round trip of tens of milliseconds. Requires WAN tuning.

None. Produce stays local at any distance because replication is out of band.

Relative cost

$$: one cluster, intra-region traffic only

$$$: cross-location replication traffic on every write

$$: two clusters, but the shadow can be provisioned for recovery rather than full production load

Tiered Storage

Supported

Not supported (including Iceberg topics and Cloud Topics)

Supported

License

Community

Enterprise

Enterprise

Deployment guide

Deploy Redpanda for Production in Kubernetes with rack awareness

Deploy a Stretch Cluster on Kubernetes

Shadowing Overview

For read-only offloading rather than disaster recovery, see Remote Read Replicas. For the lowest-cost recovery option, Whole Cluster Restore rebuilds a cluster from Tiered Storage in the same region, accepting minutes of data loss (RPO) and a high recovery time (RTO) in exchange for the lower cost of object storage.

Quick picks

  • You need zonal resilience with the lowest latency and cost: Deploy a single cluster across three or more AZs with rack awareness.

  • You need zero data loss across regions and you run Kubernetes: Deploy a Stretch Cluster.

  • You need disaster recovery across any distance, or an isolated recovery copy: Keep clusters independent and replicate with Shadowing.

  • You need to serve remote consumers without a second writable cluster: Use Remote Read Replicas.

Stretch Clusters and Shadowing

Stretch Clusters and Shadowing solve different problems and can complement each other. A Stretch Cluster is one logical cluster with synchronous replication and a single set of offsets; Shadowing asynchronously replicates data and metadata between two independent clusters for disaster recovery, protecting against events that affect a whole cluster, including some it cannot survive synchronously.

If you are deciding between the two, compare them dimension by dimension:

Stretch Cluster Shadowing

Replication

Synchronous: the Raft quorum spans locations.

Asynchronous: data is copied after the write is acknowledged.

RPO

Zero: acknowledged writes survive the loss of a location.

Greater than zero: a replication-lag window always exists.

RTO

Near zero: leaders re-elect automatically, with no cutover.

Minutes: you promote the shadow cluster and repoint clients.

Client failover

No re-bootstrap: clients keep one broker list and reconnect on their own.

Re-bootstrap required: you repoint clients to the promoted cluster. Offsets are preserved, so consumers resume where they left off.

Topology

One logical cluster with one set of offsets.

Two independent clusters: source and shadow.

Produce latency

Cross-location round trip on every acknowledged write.

Local: replication happens out of band.

Best for

Workloads that cannot lose an acknowledged write.

Disaster recovery where seconds of data loss is acceptable, or any deployment that spans distances too large for synchronous replication.

A Stretch Cluster can act as the shadow (target) cluster of a shadow link. Using a Stretch Cluster as the source cluster of a shadow link is not supported.

Next steps

Suggested labs

Search all labs