Design innovative, scalable, and highly available cloud database solutions →mediumMultiple ChoiceObjective-mapped
PCDE Practice Question: Design innovative, scalable, and highly available cloud database solutions
A gaming company uses Cloud Spanner to store player profiles and game state. The database has a table 'Players' with a monotonically increasing integer primary key. During a global launch event, write latency spikes and throughput drops. The issue is traced to hotspotting. Which schema change should the team implement to mitigate this?
⚠ Common exam trap
A common misconception in Cloud Spanner is that any random key (like a UUID) automatically solves hotspotting, but the key's distribution across splits depends on the key's prefix—without explicit salting or hashing, even UUIDs can cluster if the leading bytes are not random enough.
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
✓
Add a hash prefix to the primary key by salting the player ID.
Adding a hash prefix to the monotonically increasing integer primary key distributes writes across multiple Cloud Spanner splits, preventing hotspotting. Without this, sequential player IDs cause all new inserts to target the same split, leading to write contention and throughput drops during high-volume events like a global launch.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a hash prefix to the primary key by salting the player ID.
Why this is correct
Salting distributes writes evenly.
- ✗
Change primary key to use a combination of timestamp and player ID.
Why it's wrong here
Timestamps are monotonically increasing, still causing hotspots.
- ✗
Convert the primary key to a UUID stored as bytes.
Why it's wrong here
UUIDs are random, which helps, but the question asks about hash prefix; also UUIDs are large.
- ✗
Create a parent-child interleaved table structure.
Why it's wrong here
Interleaving affects locality but does not fix a monotonically increasing primary key hotspot.
Go deeper
Related to this question
About these practice questions
One of 1,446 original PCDE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on PCDE
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A team is designing a Spanner schema for an online gaming leaderboard. The leaderboard stores player scores and requires high write throughput. Which primary key design is BEST to avoid write hotspots?
medium- ✓ A.Primary key: (HashOfPlayerId, Timestamp)
- B.Primary key: (PlayerId, Timestamp)
- C.Primary key: (Score, PlayerId)
- D.Primary key: (Timestamp, PlayerId)
Why A: Monotonically increasing keys (like score or timestamp) cause hotspotting. Using a random prefix (e.g., hash of player ID) ensures writes are distributed across splits. Player ID alone might also cause hotspotting if many players write simultaneously.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCDE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PCDE exam.