Which Platform and Database Handle 500,000 Requests per Second?

PCA By islever Editorial Last updated

Configuring compute systems. Configuring individual storage systems. Designing a solution infrastructure that meets business requirements.

Short answer

B Use Cloud Run, which scales to zero during idle periods to cut costs, paired with Cloud Bigtable for high-throughput real-time exact-match lookups.

Question

You are implementing the infrastructure for a web service on Google Cloud. The web service needs to receive and store the data from 500,000 requests per
second. The data will be queried later in real time, based on exact matches of a known set of attributes. There will be periods where the web service will not
receive any requests. The business wants to keep costs low. Which web service platform and database should you use for the application?
  1. Cloud Run and BigQuery
  2. Cloud Run and Cloud Bigtable Correct Answer
  3. A Compute Engine autoscaling managed instance group and BigQuery
  4. A Compute Engine autoscaling managed instance group and Cloud Bigtable

Key Takeaways

The question tests whether you can match a scale-to-zero, low-cost compute service with a high-write NoSQL store; the trap is picking BigQuery simply because it supports SQL exact-match queries.

This PCA design question asks which Google Cloud compute platform plus database can ingest 500,000 requests per second, serve real-time exact-match lookups, and stay cheap during idle traffic. The pairing of Cloud Run with Cloud Bigtable satisfies every stated requirement, which is why option B is the correct choice.

Common mistake: Option D is the leading wrong pick: a Compute Engine autoscaling managed instance group keeps at least one VM (plus autoscaler overhead) running during idle periods, so it violates the low-cost scale-to-zero requirement even though Bigtable itself is right.

Expert Analysis

Why the Answer Is Correct

Cloud Bigtable is purpose-built for extreme write throughput — a single cluster sustains hundreds of thousands of writes per second — and returns row-key lookups in single-digit milliseconds, which is exactly the "exact matches of a known set of attributes" in real time that the question demands. Cloud Run complements it on the cost side: it is fully serverless, scales automatically with request volume, and scales all the way to zero instances when no requests arrive, so idle periods produce no compute charge. The 500,000 requests-per-second target is reachable because each Cloud Run instance can process up to 1,000 concurrent requests and the max-instances setting is a configurable quota, not a hard 100-instance ceiling. Together, B meets the write-rate, real-time lookup, idle-period, and low-cost requirements simultaneously.

Why the Other Options Are Wrong

Options A and C both pair the compute tier with BigQuery, which is an analytical data warehouse: it is optimized for batch-loaded columnar scans and periodic SQL reporting, not for continuously streaming 500,000 writes per second and answering millisecond point lookups, so neither can satisfy the real-time ingestion requirement. Option D selects the correct database but the wrong platform — a Compute Engine managed instance group must maintain a minimum of one healthy instance plus autoscaler machinery, so it never reaches zero and continues billing through the explicit no-traffic periods the business wants to keep cheap. It also adds operational burden (OS patching, capacity planning) versus the pay-per-request, fully managed Cloud Run model.

Community Comment Notes

Enzian argues that "Any correct answer must involve Cloud Bigtable over BigQuery since Bigtable is optimized for heavy write loads" and lands on B for cost, an assessment pakilodi reinforces by noting Cloud Run "will scale to zero." MamthaSJ, XDevX, victory108, AzureDP900, and learner311 all converge on B, with learner311 countering the scale objection by explaining that "you can scale out to 1000 cloud run containers each individually handling a max concurrency of 1000 req/sec." On the other side, gcppandit selects D by citing the default 100-instance maximum, and 6721sora picks D citing cold starts and the 10-second request-queue limit; both treat a configurable default as a fixed architectural limit. TotoroChina instead pairs Cloud Run with BigQuery, which fails the heavy-write requirement. Because the source key is listed as unknown, the verdict here rests on Google Cloud's documented service characteristics rather than on the answer key.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

Treat each clause of the scenario as a hard filter: "exact matches in real time" at 500,000 writes per second eliminates BigQuery immediately, and "periods with no requests" plus "keep costs low" eliminates any always-on instance group. Apply the filters one at a time and only one option pair — Cloud Run with Cloud Bigtable — survives both.

Frequently Asked Questions

Why is BigQuery the wrong database for 500,000 requests per second with real-time lookups?

BigQuery is an analytics warehouse built for batch loads and SQL scans; it cannot sustain continuous high-rate ingestion with millisecond point lookups, which Cloud Bigtable delivers.

Why prefer Cloud Run over a Compute Engine managed instance group for this web service?

Traffic has idle periods and cost must stay low, so Cloud Run's ability to scale to zero matters; a managed instance group must keep at least one VM running and billing.

More PCA FAQ →

Discussion 122 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 122

  1. Enzian 👍 81
    Any correct answer must involve Cloud Bigtable over BigQuery since Bigtable is optimized for heavy write loads. That leaves B and D. I would suggest B b/c it is lower cost ("The business wants to keep costs low")
  2. pakilodi 👍 21
    Not only: occasionally there will be no requests. so Cloud Run will scale to zero
  3. MamthaSJ 👍 16
    B is correct answer.
  4. gcppandit 👍 10 Answered D
    I will go with the option D. Both Cloud Run and Cloud Compute can be used to solve the problem. But the main challenge is to handle 500,000 requests per secons. In case of Cloud Run the Maximum Number of instances are allowed to 100 and each cloud run container can handle maximum 1000 requests per seconds. So if we go with Cloud Run option we can maximum address 100,000 requests per second. In case of Compute Engine (with proper external load balancer) does not have these type of limitations. So D will be better option just due to number of requests. Ref: https://cloud.google.com/run/docs/configuring/max-instances Ref: https://cloud.google.com/run/docs/about-concurrency#:~:text=By%20default%20each%20Cloud%20Run,to%20a%20maximum%20of%201000.
  5. 6721sora 👍 7 Answered D
    Not sure if B is right. Cloud Run will fail requests if waiting for more than 10 seconds. https://cloud.google.com/run/docs/tips/general If you choose Cloud Run to minimize costs during periods of no activity, then when suddenly requests come in at 5000 requests per second, a "Cold Start" occurs for Cloud Run container instances. This startup can take many seconds and during this time the requests will timeout. So a minimum number of Instance of say 1 will be required to prevent Cold Start.
Show 25 more comments
  1. XDevX 👍 7
    IMHO b) is the correct answer, not d). The requirement is to keep cost low - the quizzer says explicitly that there will be periods where the web service will not receive any requests - my impression is that the quizzer wants by using that statement to point on a solution that can scale to zero...
  2. TotoroChina 👍 7
    Answer should be A, Cloud Run and BigQuery There will be periods where the web service will not receive any requests => Cloud Run The data will be queried later in real time, based on exact matches of a known set of attributes => BigQuery
  3. victory108 👍 6
    B. Cloud Run and Cloud Bigtable
  4. learner311 👍 5
    Yeah but you can scale out to 1000 cloud run containers each individually handling a max concurrency of 1000 req/sec. https://cloud.google.com/run/docs/configuring/max-instances That would mean it can handle a soft cap of 1000 containers * 1000 req/sec = 1000000 req/sec. I'd go with B.
  5. VishalB 👍 5
    Ans B: Bigtable is optimized for real time reads & Cloud Run scales up and down from zero almost instantaneously depending on traffic. Cloud Run only charges you for the exact resources you use keeping the cost low
  6. AzureDP900 👍 5
    B is right, There is no need to go with App Engine autoscaling. Cloud Run goes to zero instances when there are no requests. Question asks cost optimization. Big Query is not suitable .. so B is right.
  7. omermahgoub 👍 4
    To handle 500,000 requests per second and store data that will be queried in real time based on exact matches of a known set of attributes, I would recommend using option D: A Compute Engine autoscaling managed instance group and Cloud Bigtable. Compute Engine autoscaling managed instance groups allow you to automatically increase or decrease the number of VM instances in a group based on workload demand. This can help ensure that your application has the resources it needs to handle high traffic periods, while minimizing costs during periods of low traffic. Cloud Bigtable is a high-performance, NoSQL database designed for extremely large scale data storage and real-time data processing. It is well-suited for applications that require fast queries and updates on large datasets, such as the one described in the question.
  8. convers39 👍 4 Answered B
    50,000 rps At first I thought Cloud Run could not handle this request rate and then chose D. After a little bit of research on the docs I changed my mind to B. On each instance concurrency, it clearly says > By default each Cloud Run instance can receive up to 80 requests at the same time; you can increase this to a maximum of 1000 https://cloud.google.com/run/docs/about-concurrency The maximum number of auto-scaling instances by default is 100, which can be configured depending on the regional quota. With the default max instances it can already handle 100 * 1000 = 100,000 requests concurrently, which should be able to achieve the 50,000 rps requirement. https://cloud.google.com/run/docs/about-instance-autoscaling
  9. JohnPi 👍 4 Answered B
    Container instance | Maximum number of container instances | 1000 | per service Request | Maximum number of concurrent requests | 1000 | per container instance 1000*1000 > 500000
  10. pancakes22 👍 4 Answered B
    https://cloud.google.com/run/quotas There is no direct limit for: The size of container images you can deploy. The number of concurrent requests served by a Cloud Run service.
  11. AmitRBS 👍 4
    B. Agree. Additionally data need to store now so use Bigtable as question is not for analysing or data Analytics etc
  12. pakilodi 👍 4 Answered B
    B. Because cloud run can scale to zero and for such heavy loads, it needs bigtable
  13. muky31dec 👍 3 Answered D
    must D Concurrency values Concurrency is configurable. By default each Cloud Run container instance can receive up to 80 requests at the same time; you can increase this to a maximum of 1000. Note that in comparison, Functions-as-a-Service (FaaS) solutions like Cloud Functions have a fixed concurrency of 1. Although you should use the default concurrency value, if needed you can lower the maximum concurrency. For example, if your code cannot process parallel requests, set concurrency to 1. The specified concurrency value is a maximum and Cloud Run might not send as many requests to a given container instance if the CPU of the instance is already highly utilized. The following diagram shows how the concurrency setting affects the number of container instances needed to handle incoming concurrent requests:
  14. tamer_m_Saleh 👍 3 Answered D
    At first I through its B, but then I thought about the number of requests that will be over 1 minute, if we calculated it = 30 million request per minute, and based on cloud run pricing this will cost only for the number of requests: 24 USD. so cloud run will cost the company 24 USD / min. which might be a very costly option. But in the cloud run pricing there is 2 modes: - CPU allocated when receiving requests: and there is a cost for CPU and requests - CPU always allocated: and there is only a cost for the CPU and zero price for the number of requests. I think we need someone experiencing the billing of a cloud run under a heavy load like this :)
  15. omermahgoub 👍 3
    Cloud Run, on the other hand, is a fully managed serverless platform for deploying and scaling containerized applications. While it may be a good choice for some applications, it may not be the best fit for an application that needs to handle high levels of traffic and perform real-time queries on large datasets. BigQuery is a fully managed, cloud-native data warehouse that is well-suited for analyzing large datasets using SQL. However, it may not be the best choice for an application that needs to perform real-time queries on large datasets, as it is optimized for batch processing rather than real-time querying.
  16. JC0926 👍 3 Answered B
    Cloud Run is a serverless platform that allows you to run stateless containers on demand. It can scale quickly to handle a large number of requests and automatically scales down to zero when there are no requests, making it a cost-effective option. Cloud Bigtable is a NoSQL database that is designed for handling massive amounts of data with low latency and high throughput. It can handle up to millions of operations per second, making it a suitable option for storing and querying the large volume of data generated by the web service.
  17. brvinod 👍 3 Answered B
    I would vote for B. EVen though there is a max concurrency of 1000, there is no upper limit to the number of containers (unless we specify). So, CloudRun will spawn as many containers as needed to run the number of requests and take care of all the requests. Let me know if you have different interpretation of this link> https://cloud.google.com/run/docs/about-instance-autoscaling
  18. mkc110891 👍 3 Answered D
    The answer is D: The default concurrency limit in the Cloud Run is 80 req/sec, which can be increased up to 1000 req/sec. Here in the question, they are talking about 500000 req/sec which is a way higher number. So it can be managed using autoscaling MIG. https://cloud.google.com/run/docs/about-concurrency#concurrency_values
  19. BrijMohan08 👍 3
    Answer D infrastructure for a web service - VM (Compute Engine) data will be queried later in real-time - Bigtable There will be periods where the web service will not receive any requests - autoscaling managed instance group
  20. MarcExams 👍 3
    Answer is B. Big table is amazing for REAL-TIME Analysis strong with heavy read/write events refer to: https://cloud.google.com/blog/topics/developers-practitioners/bigtable-vs-bigquery-whats-difference
  21. Petya27 👍 3
    Plus, we are talking about a predefined set of queries. For any predefined list of (simple) queries, we use Bigtable, and for any (complex) queries that we do not know ahead of time, we use BigQuery.
  22. nick_name_1 👍 3
    Run can scale to 1,000 instances without requesting a quota increase. Each instance can handle up to 1,000 concurrent requests. 500,000/sec is half the maximum for Run. Run scales to zero.
  23. santoshindia 👍 3 Answered D
    By default each Cloud Run container instance can receive up to 80 requests at the same time; you can increase this to a maximum of 1000 https://cloud.google.com/run/docs/about-concurrency
  24. Santanu_01 👍 3
    The solution should have Cloud Run (as it can scale from 0 to many) so when not in use no cost involved and Cloud Bigtable -- concerning throughput on the problem satement
  25. zr79 👍 3
    there will be a cost associated with your VM even if they have 0 traffic as GCE is an IaaS. You're billed for resources provisioned and the company wants to reduce cost

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Multi-Regional vs Regional Cloud Storage for Global Software Downloads

S-grade

Surviving a Zone Outage With SQL Server on GCP

S-grade

Fixing BigQuery connection errors from a Compute Engine VM

S-grade

Moving 75 TB into Cloud Storage with Google-recommended practices

S-grade

Practice All PCA Questions

Access 81 questions with complete answers and detailed explanations.

View Full PCA Practice Test →

← Back to PCA Study Guide