Skip to content

CONCEPT Cited by 3 sources

Leader pinning

Definition

Leader pinning is the mechanism by which an operator specifies preferred locations (regions, racks, or AZs) for the partition leaders of a topic on a multi-region or multi-AZ streaming cluster, so that write and (leader-served) read traffic for that topic routes to brokers geographically close to the clients. It is the write-path locality optimisation on a stretch cluster, dual to follower fetching's read-path locality.

Canonical Redpanda framing

"Leader pinning is a feature in Redpanda that lets you specify preferred locations for topic partition leaders and pin to specific regions in a multi-region cluster. Leader pinning ensures a topic's partition leaders are geographically closer to clients. This helps decrease networking costs and guarantees lower latency by routing produce/consume requests to brokers located in specific regions."

(Source: sources/2025-02-11-redpanda-high-availability-deployment-multi-region-stretch-clusters)

Why it exists — the baseline to beat

By default, Kafka/Redpanda elect partition leaders without regard to client locality. On a stretch cluster spread across three regions, a topic's partitions may end up led in any region, forcing producers and consumers in region A to round-trip to region B or region C on every produce/consume request. Two costs stack up:

  1. Latency tax = cross-region RTT on every request (60+ ms for us-east-1 ↔ us-west-1, 150+ ms transoceanic). Multiplies out to a write SLA blow-up on stretch clusters even before acks=all quorum is considered.
  2. Bandwidth tax = cross-region egress billing on every produce/fetch payload; cloud providers charge cross-region data transfer separately.

Leader pinning eliminates both by biasing the cluster's leader assignment so that each topic's leaders live in the clients' region.

How it composes with cross-region quorum

Leader pinning does not weaken strong-consistency. The partition still has followers in other regions; acks=all still requires cross-region Raft quorum on commit. What changes is the client-facing hop: the client-to- leader RTT is intra-region (single-digit ms) instead of cross- region (60+ ms). The quorum-wait is unchanged. So the per-write latency becomes client_to_leader_intra_region + cross_region_quorum_RTT instead of client_to_leader_cross_region + cross_region_quorum_RTT — you save the client-side half but still pay the replication-side half.

In contrast, producer acks=1 relaxes the quorum wait entirely — the two mitigations are orthogonal:

  • Leader pinning: preserve durability, bias topology.
  • acks=1: preserve topology, degrade durability.

Composed together (acks=1 + leader pinning), a produce becomes an intra-region-leader-only round-trip — the lowest-latency configuration a stretch cluster can offer, at the cost of region- outage durability.

Per-topic configuration, not per-cluster

Leader pinning is applied per topic — different topics can pin leaders to different regions. This matters because different tenant workloads typically cluster client traffic by region (analytics in us-east, real-time trading in eu-west, telemetry in ap- southeast), so the right pinning assignment is topic-specific.

Licensing / availability

Leader pinning is an enterprise feature on Redpanda:

"Leader pinning is an enterprise feature that requires a valid license. It's available for both Self-Managed Redpanda clusters and Redpanda Cloud."

This is a soft-paywall caveat — the first-line latency mitigation on a stretch cluster is a commercial licence gate on Self-Managed.

Upstream Kafka equivalence

Upstream Apache Kafka does not ship a single-knob leader-pinning feature; the equivalent is typically achieved via preferred replica election + rack-aware replica placement, which controls placement but not leadership affinity per se. Redpanda's leader-pinning feature is a direct productisation of the client-proximal-leader pattern.

Seen in

Last updated · 542 distilled / 1,571 read