Skip to content

PATTERN Cited by 1 source

Cross-region read via object storage

Intent

Serve read traffic in regions where producers do not live by reading segment files from the shared object store instead of replicating the stream to a second broker cluster. Producers keep writing to the origin cluster; consumers in other regions read from region-local Redpanda clusters whose data source is the same object-storage bucket. The origin cluster experiences no read load from the remote consumers, and no cross-region Raft quorum is required.

This is the cross-region extension of the same-region remote read replica primitive: same shape, with cross-region object-storage replication in the substrate.

Canonical framing

From the Redpanda 26.1 launch post:

"Cross-Region Remote Read Replicas for AWS allow you to decouple your global read traffic from your production cluster. By accessing topics through S3 instead of the network, you can serve reads in AWS regions worldwide without putting any workload on the production cluster, at a much lower cost than using a 'stretch' cluster. It's the easiest way to scale reads globally without the operational overhead stretch or multi-cluster replication."

Paired with ranked rack preferences in the same release as the write-path / read- path dual: ranked preferences keep leaders close to producers (write-path), cross-region RRR serves reads in consumer regions (read-path).

Mechanism

 REGION us-east-1              REGION us-west-2         REGION eu-west-1
 ┌──────────────────┐          ┌──────────────┐         ┌──────────────┐
 │ Redpanda         │          │ Read-only    │         │ Read-only    │
 │ origin cluster   │          │ RRR cluster  │         │ RRR cluster  │
 │ (producers       │          │              │         │              │
 │  + leaders)      │          │ No writes    │         │ No writes    │
 └────┬─────────────┘          └──────┬───────┘         └──────┬───────┘
      │ writes + tiered              ▲                         ▲
      │ storage segment              │ reads from replicated   │
      ▼ upload                       │ bucket                  │
 ┌──────────────────┐  cross-region  │                         │
 │ S3 bucket        │  replication   │                         │
 │ us-east-1        ├────────────────┼─────────────────────────┘
 │ (segments)       │                │
 └────────┬─────────┘                │
          │                          │
          ▼                          │
 ┌──────────────────┐                │
 │ S3 bucket        │                │
 │ us-west-2        │────────────────┘
 │ (cross-region    │
 │  replicated)     │
 └──────────────────┘
  1. Producers write to origin cluster in us-east-1.
  2. Origin cluster uploads segments to S3 in us-east-1 (standard tiered-storage / Cloud Topics flow).
  3. S3 cross-region replication mirrors segments to region- local buckets in us-west-2 / eu-west-1.
  4. Read-only RRR cluster in each consumer region serves reads by fetching segments from its region-local bucket.
  5. Consumers connect to the region-local RRR cluster, not the origin.

Origin cluster read-load: zero from remote regions. Cross-region network cost: paid once per segment at S3-replication rates, amortised across every consumer in the destination region.

Contrast with alternative shapes

Shape Write quorum Read path Cross-region cost driver Operational cost
Stretch cluster Cross-region Raft Any region Every produced byte ×RF High: operator-tunes multi-region Raft
Multi-cluster active-passive replication (MM2, Shadowing) Origin-region quorum Replica cluster reads Every produced byte copied Medium: MM2 / Shadowing ops
Cross-region RRR via object storage Origin-region quorum Region-local RRR cluster via replicated bucket Every segment replicated once (S3 x-region replication rate) Low: S3 handles the replication

The cost structure makes cross-region RRR attractive for read- fan-out-dominated workloads: one cross-region byte replicated serves unlimited region-local consumers.

When to use

  • Consumer fleet spans regions that producer fleet does not — observability data produced in us-east-1 consumed by compliance teams in eu-west-1; model-training features produced in one region trained in another.
  • Consumer read rate ≫ producer write rate — the per-byte cross-region replication cost amortises across many reads.
  • Origin cluster is capacity-constrained — offloading cross-region reads protects the origin cluster's SLO.
  • Stretch-cluster operational overhead is unacceptable — teams without multi-region Raft expertise.

When to avoid

  • Read freshness requirements are tight (sub-second) — S3 cross-region replication adds seconds-to-minutes of lag before segments are visible in the destination region. Object-store access latency from consumer clients adds 40- 200 ms per fetch depending on region pair.
  • Low read-to-write ratio — if reads barely exceed writes, the cross-region replication cost isn't amortised and a direct network fetch may be cheaper.
  • Strong consistency across regions required — the pattern is eventually-consistent across regions.

Trade-offs

  • Read freshness: bounded by S3 cross-region replication lag + local RRR cluster's metadata catch-up.
  • Cross-region bandwidth cost: one S3 replication cost per segment, not per consumer.
  • Regional isolation: each region's RRR cluster is independently sized; one region's read spike doesn't hit other regions.
  • AWS-only at launch — the 26.1 post specifies AWS S3 explicitly. No disclosed mechanism for GCP / Azure yet.

Mechanism gaps (from the source)

The 26.1 launch post is one paragraph of product framing. Undisclosed:

  • Cross-region bucket replication: customer-configured S3 CRR? Redpanda-managed replication? Timeline semantics?
  • RRR cluster provisioning model: Redpanda Cloud-hosted in each region? Customer-provisioned via BYOC?
  • Read-consistency guarantees: per-partition ordering only, or region-wide?
  • Leadership / metadata: the RRR cluster has no leaders (read-only) — what's the metadata store shape?

Canonical instance

Redpanda 26.1 Cross-Region Remote Read Replicas for AWS — positioned as the easiest way to scale reads globally without stretch-cluster or MM2-class multi-cluster replication operational overhead. Builds on the 26.1 Cloud Topics object-storage- native substrate that already writes payloads directly to S3.

Paired pattern

  • patterns/client-proximal-leader-pinning + ranked rack preferences (the 26.1 write-path enhancement) — the write-path counterpart. Producers talk to leaders in their region; consumers talk to RRR clusters in their region. Neither path traverses cross-region hops.

Seen in

Source

Last updated · 550 distilled / 1,221 read