Reducing Cross-Region Messaging Latency with Pulsar Geo-Replication

The problem: waiting on cross-region messages

If your application publishes events in one data center and consumers in another region need those events quickly, you usually face a choice: accept the round-trip latency of a distant broker, or build and operate a custom replication pipeline. Both options add operational cost and failure surface.

What Pulsar geo-replication does

Apache Pulsar separates serving (brokers) from storage (BookKeeper) and namespaces from topics. Geo-replication is a namespace-level feature: you configure a cluster as a peer, and Pulsar copies messages from a source cluster to a destination cluster over the WAN. Consumers in the destination region read from a local replica instead of crossing the ocean for every message.

This is not a general database mirror. It replicates messages on topics within a namespace, and it works best when you size partitions and replication clusters for your expected throughput.

Worked example: three regions

Assume you run a recent Pulsar release. Confirm geo-replication API support in your version's release notes before proceeding. You have:

• us-east: source cluster where producers publish
• eu-west: replica cluster for European consumers
• ap-south: replica cluster where an Asia-Pacific consumer group reads

First, add the peer clusters to the namespace. Run the following from a host that can reach the Pulsar admin API, using an account with namespace administration rights:

bin/pulsar-admin namespaces add-clusters \
  my-tenant/my-namespace \
  --clusters us-east,eu-west,ap-south

Then enable replication for the namespace:

bin/pulsar-admin namespaces set-replication-clusters \
  my-tenant/my-namespace \
  --clusters us-east,eu-west,ap-south

Verify the policy with the admin API endpoint /api/v1/namespaces/{tenant}/{namespace}/replication. A successful response lists the configured peer clusters and their replication status.

Now create a topic and publish. Consumers in eu-west and ap-south can subscribe to the same topic name and read locally replicated messages. You do not need a separate topic per region.

Diagnostic decision: check replication lag

After publishing a test batch, inspect replication lag through Pulsar metrics or the admin UI. If lag climbs steadily, the bottleneck is usually WAN bandwidth or insufficient partitions, not the replication feature itself.

Trade-offs and limitations

• Extra network traffic. Every replicated message crosses the WAN at least once. Budget for inter-region data transfer costs.
• Partition hot-spikes. Too few partitions can concentrate traffic on a single broker and increase latency. Add partitions before you hit capacity, not during an incident.
• Ordering and duplication. Cross-region latency spikes can affect per-partition ordering guarantees, and misconfigured replication factors can cause message duplication or loss. Test with a small topic before production rollout.

Verify before you rely on it

1. Confirm your Pulsar release supports the geo-replication API; older releases may lack full support.
2. Run a producer/consumer test across regions and measure end-to-end latency and ordering.
3. Check /api/v1/namespaces/{tenant}/{namespace}/replication to confirm the policy is active for the target topic.

Geo-replication removes the need for custom cross-region plumbing, but it is not a set-and-forget feature. Start with one namespace, measure lag under load, and expand partitions and clusters as your traffic grows.