Cloud Digital Leader Scaling with Google Cloud operations Practice Question

A global gaming company uses Cloud Spanner for their leaderboard. They notice that write latency spikes during peak hours. The database is currently deployed in a single region. Which scaling strategy should they implement to reduce write latency globally?

⚠ Common exam trap

Google Cloud often tests the misconception that scaling a database horizontally by adding nodes always reduces latency, but in a single-region Spanner setup, adding nodes only increases throughput and storage, not geographic proximity, which is the root cause of high write latency for global users.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use Cloud Spanner multi-region configuration.

Cloud Spanner's multi-region configuration is designed to reduce write latency for globally distributed users by placing write-capable replicas in multiple geographic regions. This allows writes to be committed at the nearest replica, leveraging Spanner's TrueTime and Paxos-based replication to maintain strong consistency across regions. A single-region deployment forces all writes to a single location, causing high latency for distant clients during peak hours.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Use Cloud Spanner multi-region configuration.
Why this is correct
Cloud Spanner multi-region configurations replicate each tablet across chosen regions and let you designate a default leader region for writes. Because every write commit is coordinated by the Paxos leader and its synchronous quorum, placing that leader near your gaming company's player-facing service reduces the network distance (RTT) for leaderboard score updates. Multi-region configurations also add regional and read-only replicas, so reads can be served close to players while write latency from remote locations drops substantially.
✗
Implement application-level caching with Memorystore.
Why it's wrong here
Adding a Memorystore cache helps read-heavy leaderboard pages by serving rankings from memory and reducing read latency, but it does not reduce the latency of the write operations that post a player's score. The new score must still travel to the Cloud Spanner single-region instance, be processed in the same regional Paxos group, and return an acknowledgment to the client; the cache is only updated after that commit, so the remote write round-trip remains exactly as slow. A cache also risks serving stale ranking data between invalidations.
✗
Change to Cloud Bigtable for higher throughput.
Why it's wrong here
Cloud Bigtable is a wide-column, NoSQL database built for extremely high read/write throughput on large time-series and key-value workloads, not for relational leaderboard queries. It supports only single-row transactions, so an update that bumps a player's score and atomically recalculates a global rank requires application-level handling, and its SQL query capabilities are limited. Furthermore, moving to Bigtable would still need a multi-region or replicated deployment to shrink write RTT; the original issue is geographic distance, not throughput capacity.
✗
Add more nodes to the existing Spanner instance.
Why it's wrong here
Scaling out a Cloud Spanner instance by adding nodes improves throughput by splitting the key space into smaller tablets and distributing load, but it does not relocate the instance's replicas or narrow the distance between a remote game client and the region. Each leaderboard write must still be committed by the same single-region Paxos group, so the round-trip time for users on other continents is unchanged. Node count is a capacity lever, whereas the latency fix for globally distributed players requires geographic placement or multi-region configuration.

Go deeper

Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Why each option matters

Option-by-option breakdown

Related to this question