You have 10 PB of historical product data for analytics and 10 GB of each product's last-known state that must serve an API at up to 1000 QPS with <1s latency. What storage design is cost-effective and meets analytics and API needs?

The correct option leverages BigQuery for its cost-effectiveness and scalability with 10 PB of historical data, ideal for analytics. For the 10 GB of last-known state requiring low-latency API access at 1000 QPS, Cloud SQL is a suitable choice. Its relational database capabilities provide consistent, fast reads for transactional data. The first incorrect option's approach of serving the last state directly from BigQuery to the API is problematic due to BigQuery's query latency, which is typically seconds to minutes, not sub-second, making it unsuitable for high QPS, low-latency OLTP workloads. The second incorrect option, using Firestore for 10 PB of historical data, would be prohibitively expensive and inefficient for analytical queries compared to BigQuery. The third incorrect option, Cloud SQL for 10 PB of historical data, would be extremely expensive and struggle with the scale of analytical queries, as Cloud SQL is designed for transactional workloads, not petabyte-scale analytics.