Cloud Digital Leader Google Cloud Products and Services Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Cloud SQL

  Why it's wrong here

  Cloud SQL is a relational database with a single-primary write model, which caps effective write throughput at roughly tens of thousands of transactions per second at the high end. Even with read replicas, all writes must serialize through the primary, making it impossible to absorb millions of concurrent writes per second for a real-time leaderboard. Additionally, maintaining such a write spike requires aggressive connection pooling and sharding that undermines the SQL simplicity without ever guaranteeing the needed latency ceiling.

• ✗

  Firestore

  Why it's wrong here

  Firestore is a document database with a per-document write limit of about 1 write per second and a sustained database-wide write ceiling that scales with documents but is not designed for millions of writes per second in a single hot key space. A real-time leaderboard constantly updates a small set of high-score records, creating severe write contention on those documents and causing hot-spot throttling or quota exhaustion. Firestore is better suited for moderate, distributed write patterns and near-real-time sync, not ultra-high-frequency updates to shared ranking keys.

• ✓

  Cloud Bigtable

  Why this is correct

  Cloud Bigtable is a NoSQL wide-column database engineered for high-throughput, low-latency writes of millions of rows per second when scaling with CPU and storage nodes. Its distributed storage engine appends writes to SSTables with memtable buffering, giving consistent single-digit-millisecond latencies and linear write scaling across a cluster without a single bottleneck. For a real-time leaderboard, Bigtable's row-key design (like inverted scores or user IDs) paired with its massive write capacity makes it a proven choice for globally hot update streams.

• ✓

  Memorystore for Redis

  Why this is correct

  Memorystore for Redis provides an in-memory data structure server whose sorted set operations (ZADD, ZRANGEBYSCORE, ZREVRANK) are O(log N) and can handle millions of operations per second across a single Redis instance with sub-millisecond latency. These sorted sets are literally built for leaderboard ranking, allowing instantaneous insertion of new scores and O(log N) rank lookups without requiring external computation. While Memorystore can hit millions of operations per second on a single instance, it is limited by available memory and instance size, but for a leaderboard dataset that fits in RAM it is an equally correct and extremely fast option.

• ✗

  BigQuery

  Why it's wrong here

  BigQuery is an analytical columnar warehouse designed for massively parallel scans of petabytes, not transactional row-level updates at millions of writes per second. Each streaming insert into BigQuery is batched and subject to quota and latency constraints, making it unsuitable for real-time score writes that must be immediately reflected in the leaderboard. BigQuery is better used to analyze historical leaderboard data or run complex aggregations after the fact, not to serve as the live write front-end for a leaderboard.

Go deeper

Related to this question