Google ACE Practice Question: A media company ingests 500,000 events per second…

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 Firestore

  Why it's wrong here

  Cloud Firestore is a document-oriented NoSQL database designed for mobile and web app backends, not for high-throughput time-series analytics. Its write capacity is bounded by document-level limits—at most one write per second per document—and scaling to 500K writes/second would require massive sharding and still not yield the columnar storage needed for analytical queries. Firestore also prioritizes ACID transactions and real-time listeners, which are irrelevant to an IoT event pipeline and add overhead that hampers throughput.

• ✗

  Cloud SQL for MySQL

  Why it's wrong here

  Cloud SQL for MySQL is a fully managed relational database with write throughput typically capped at a few thousand queries per second, far below the required 500K events/second. Its B-tree indexes and row-based storage introduce overhead for every insert, and to approach the target you would need aggressive sharding and connection pooling, which defeats the purpose of a managed relational service. It is not designed for real-time event ingestion or columnar time-series analytics, making it structurally unsuited for this workload.

• ✓

  Cloud Bigtable

  Why this is correct

  Cloud Bigtable is purpose-built for high-throughput, low-latency NoSQL workloads, including IoT time-series ingestion at 500K events/second. It scales linearly by adding nodes, supports millions of writes per second, and uses row keys like device timestamp to enable fast point reads and range scans. Its wide-column storage model is optimized for analytical patterns over sequential time-series data, making it the ideal choice over relational or document databases.

• ✗

  BigQuery streaming inserts

  Why it's wrong here

  BigQuery streaming inserts are not built for sustained 500K events/second raw ingestion: the streaming API has a default limit of 100,000 rows per second per table and a streaming buffer that adds latency and eventual consistency to reads. It is more effective as an analytics sink downstream of a buffering layer such as Pub/Sub, where data is batched and loaded via the Storage Write API. For this real-time ingestion workload, BigQuery would quickly hit quota ceilings and incur high costs without providing the low-latency write path required.

Go deeper

Related to this question