Reduce Spanner Write Latency with Leader-Aware Routing

PCDBE By islever Editorial Last updated

Optimize database cost and performance in Google Cloud. Determine how applications will connect to the database.

Short answer

A Enable leader-aware routing in the client library so the write-heavy multi-region Spanner workload reaches the leader replica without cross-region forwarding.

Question

Your company is using a multi-region Spanner instance. The instance stores data from an application which does a lot of writes without reading the data. You are noticing a lot of latency regression. You want to reduce latency and improve performance. What should you do?
  1. Enable leader-aware routing in the client library. Correct Answer
  2. Add additional indexes to the table.
  3. Disable leader-aware routing in the client library.
  4. Increase the number of Spanner nodes.

Key Takeaways

The test is whether you know that Spanner writes must go through the leader replica and that leader-aware routing removes the extra network hop, rather than treating the problem as a read or capacity issue.

For a write-heavy multi-region Spanner instance suffering latency regression, enabling leader-aware routing in the client library (A) sends writes directly to the leader replica, removing the cross-region forwarding hop that causes the delay.

Common mistake: Option D (increase the number of Spanner nodes) is the most plausible trap: it looks like a standard performance fix, but more nodes scale throughput and storage, not the per-write latency caused by routing to a non-leader region.

Expert Analysis

Read the constraint first: "does a lot of writes without reading." That qualifier is the whole question. In a multi-region Spanner instance, every write must be committed by the leader replica. If your client library is not configured to know where the leader lives, requests are sent to a local (non-leader) replica or a home region and then forwarded across regions to the leader, adding a network round trip on every write. The latency regression you are seeing is that forwarding penalty, so the fix must target where the client sends its requests.

Why option A is correct. "Enable leader-aware routing in the client library" makes the client send requests directly to the leader region, eliminating the extra hop for a write-dominated workload. This is exactly the scenario Google's leader-aware routing guidance describes: workloads with a high write-to-read ratio benefit because writes cannot be served by read-only replicas anyway.

Why the other options fail the wording. Option C is the direct opposite of the required action — disabling leader-aware routing keeps the cross-region forwarding and preserves the latency. Option B, adding indexes, addresses read and query performance; the question explicitly states the application does not read, so indexes add write amplification and cost without reducing the write path latency. Option D, increasing Spanner nodes, scales throughput and storage, not per-request network latency — more nodes do not remove the leader-forwarding hop, and the question asks to reduce latency, not to add capacity.

The decisive word. "Reduce latency" rules out capacity-oriented answers (B, D) and the negating answer (C), leaving A as the only action on the client's connection path to the leader.

Official Reference

https://cloud.google.com/spanner/docs/leader-aware-routing

This link opens the official vendor documentation in a new tab.

Exam Strategy

On Spanner performance questions, first classify the workload as read-heavy, write-heavy, or mixed, because writes can only be served by the leader replica. Then check whether an option changes the client's path to the leader (routing) or only adds capacity (nodes) or read helpers (indexes). When the stem says writes dominate and reads are rare, routing-to-leader options beat scaling options almost every time.

Frequently Asked Questions

What does leader-aware routing do in a multi-region Spanner instance?

It configures the client library to send requests directly to the region hosting the leader replica. Because writes must be committed by the leader, this removes the extra cross-region hop that occurs when a client talks to a non-leader replica first.

Would adding Spanner nodes reduce write latency?

No. Increasing nodes scales throughput, storage, and CPU headroom, but it does not change the network path a write takes to reach the leader. It also raises cost without addressing the routing-based latency described in the question.

Why are indexes the wrong fix when the app rarely reads?

Indexes accelerate read and query paths, but each index must also be maintained on every write, increasing write amplification. Since the workload does little reading, indexes add overhead rather than reducing latency.

More PCDBE FAQ →

Community Votes

A
67%
C
33%

67% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 2 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 2

  1. AwesomeGCP 👍 1 Answered A
    The correct answer is A. Enable leader-aware routing in the client library.
  2. sian95 👍 1 Answered C
    https://cloud.google.com/spanner/docs/leader-aware-routing

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Scheduling Cloud SQL Exports with Cloud Scheduler and Pub/Sub

S-grade

Connecting GKE to AlloyDB Across Isolated VPCs

S-grade

Migrating Cloud SQL PostgreSQL PITR Logs to Cloud Storage

S-grade

Using Service Accounts for Cloud SQL Auth Proxy on Compute Engine

S-grade

← Back to PCDBE Study Guide