A live TV show asks viewers to cast votes using their mobile phones. The event generates a large volume of data during a 3-minute period. You are in charge of the "Voting infrastructure" and must…

Question

Exhibit

Options

• ACreate a Memorystore instance with a high availability (HA) configuration.
• BCreate a Cloud SQL for PostgreSQL database with high availability (HA) configuration and multiple read replicas.
• CWrite votes to a Pub/Sub topic and have Cloud Functions subscribe to it and write votes to BigQuery.

Explanation

Option C is correct because Pub/Sub is purpose-built for high-throughput, durable message ingestion - ideal for absorbing a sudden 3-minute vote spike without dropping messages. Cloud Functions scale automatically (serverless) to process votes as they arrive, and BigQuery supports both streaming inserts for real-time partial results and cost-efficient batch aggregation after voting closes, satisfying the "count exactly once, optimize cost" requirement.

A is wrong because Memorystore is an in-memory cache (Redis/Memcached), not a durable processing pipeline. It has no built-in analytics, and data is volatile - votes could be lost if not explicitly persisted elsewhere.

B is wrong because Cloud SQL under massive concurrent writes becomes a bottleneck; it's designed for transactional workloads, not event ingestion at scale. Running HA plus multiple read replicas also violates the cost-optimization requirement.

Memory tip: Think of this as a classic ingest → process → analyze pipeline. Whenever you see "high burst traffic + durable processing + analytics + cost optimization," map it to Pub/Sub → Cloud Functions → BigQuery - Pub/Sub buffers the burst, Functions scale to zero, BigQuery charges only for queries run.

No community discussion yet for this question.