Which Platform and Database Handle 500,000 Requests per Second?
Configuring compute systems.
Configuring individual storage systems.
Designing a solution infrastructure that meets business requirements.
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?
Answer
Correct 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.
Community Insight
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.
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.
Community Discussion (124 comments)
Abhi_ma_cdl_22
👍 2
Selected: B
BigTable for heavy write loads Cloud Run for low cost and scale down capability
Armne96X
👍 2
Selected: B
Cloud Run and Cloud Bigtable is the best choice because it meets all the requirements: Cloud Run can scale automatically to handle 500,000 requests per second and scales to zero during periods of no requests, reducing costs. Cloud Bigtable is designed for real-time queries with exact match attributes. Autoscaling Managed Instance Group can not scale to zero during periods of no requests*
afsarkhan
👍 1
Selected: D
It's hard for Cloud Run to scale to accept 500k rps so choosing Option D
yas_cloud
👍 1
Not sure why this is voted between B and D. It should be A. MIG wont support, that rules out C and D. between BQ and BT, please see that "data will be queried later in real time, based on exact matches of a known set of attributes". This is supported by BQ alone. So I would go with A.
Tirthankar17
👍 2
Selected: B
B is correct
pancakes22
👍 4
Selected: 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.
the1dv
👍 2
Selected: D
Cloud Run can handle this amount if there were like 500 instances which would cost a pretty ridiculous amount per minute, so unfortunately there isnt enough information in this question around how long the gaps are without data to make a proper decision. Autoscaling Managed Instance Groups can scale to zero and 500k per second would be relatively easily handled by a few instances.
convers39
👍 4
Selected: 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
afsarkhan
👍 1
question says it's 500k and not 50k rps
kshlgpt
👍 1
Selected: D
Cloud Run can't support 50,000 requests per second. Correct answer should be D.
pancakes22
👍 3
That's incorrect. https://cloud.google.com/run/quotas
kshlgpt
👍 1
Cloud Run can't handle 50,000 requests per second A & B is eliminated
wly_al
👍 1
Not receive any request = Cloud Run
tamer_m_Saleh
👍 3
Selected: 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 :)
Andoameda9
👍 1
Selected: B
Apart from the reason that cloud run can scale to zero, another benefit in this scenario is the fact Cloud run will provide out of the box revision maintenance for the web service.
odacir
👍 1
Selected: B
Compute: Cloud Run vs. Compute Engine autoscaling managed instance group Cloud Run wins because can scale down up to 0 instances -> in Spike workflows will be cheaper. Storage: BigQuery vs. Big Table. 500,000 requests per second it’s not suitable in BQ: https://cloud.google.com/bigquery/quotas “A user can make up to 100 API requests per second to an API method” So answer most be B.
thewalker
👍 1
MIGs cannot scale the VMs to 0 as per https://cloud.google.com/compute/docs/autoscaler/scaling-cloud-monitoring-metrics#configure_utilization_target So B is the answer.
DinRush
👍 1
Cloud Functions can also scale to 0. But I guess because it manageable scaling can be done faster on functions level
AdityaGupta
👍 1
Selected: B
Answer should B, beasue Data is no SQL data, real-time analysis needed. -> BigTable Cloud Run will help in -> Low Cost (Zero when no event)
Frusci
👍 2
Selected: B
B is the correct answer. Cloud Run will scale down to zero when there's not requests. As the data will be queried in real-time Big Table is appropriate.
Rinku5005
👍 1
Selected: B
occasionally there will be no requests and bussiness wants to keep the cost low. B is the Right Choice
capt2101akash
👍 1
Selected: B
Cloud run scales as per needs and bigtable is best for high throughput low latency use cases.
kilo10x
👍 1
option B- there wont be any request at times that gives Cloud Run as the answer and real time heavy writes gives Big Table
JohnWick2020
👍 3
Answer is B. Here are the clues: Heavy writes = BigTable Low cost (scales to zero) = Cloud Run. BQ is ruled out because it's OLAP more for reads than write.
non_90919
👍 1
According to ChatGPT, "Option B (Cloud Run and Cloud Bigtable) is not the optimal choice because Cloud Bigtable is a NoSQL wide-column database that is more suitable for handling large-scale, high-throughput analytical workloads rather than real-time querying based on exact matches." So everyone is just saying something different lol
BiddlyBdoyng
👍 3
BigQuery has a 100k read/s quota, I can't write the quota for writes but would be confident BigQuery cannot handle 500k/s. Bigtable is designed for such massive IO.
Fu7ed
👍 1
Selected: B
The problem is that I want a low cost, so I'll choose cloud run. Cloud run does not incur costs when not running, and auto scale is also possible. I will choose Bigtable because I need to handle a large amount of throughput. So the answer is D. Please let me know if there are any mistakes.
salvo007
👍 1
bigtable is ok for me, not bigquery. Cloud RUN has limits. https://cloud.google.com/run/quotas?hl=it 1000 cloud run instances, is the maximum number. with 500000 request/sec. I have 500000/1000=500 request for instance cloud run has max number of parallel request per instance = 1000 so is ok but max number of parallel data flows per instance = 100 the right answer is D
balajisreenivas
👍 1
Selected: B
B is correct since cost should be low.
JC0926
👍 1
Selected: B
Based on the requirements and constraints mentioned, the recommended web service platform and database for the application would be Cloud Run and Cloud Bigtable, option B. Cloud Run is a serverless compute platform that allows for automatic scaling and provides a low-cost option for applications with unpredictable or variable traffic patterns. Cloud Bigtable is a NoSQL database that is designed for high-throughput, low-latency workloads and can handle large amounts of data. It is also fully managed, so it does not require significant administration overhead.
JC0926
👍 3
Selected: 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.
Deb2293
👍 2
Selected: B
Cloud Run can scale to 0 so should be B
telp
👍 2
Selected: B
Cloud run scale to 0 so reduce cost when no activity. Bigtable to support the heavy write.
segkhachat
👍 1
MIG would not scale as fast as Run. With this high throughput I would rather use containerized solution instead of VMs as for each VM instance you are going to have a separate OS. So you may need more memory with GCE which does not support scale from 0.
segkhachat
👍 1
The only doubt I have is because of a mentioned 'infrastructure' keyword in the question.
gcppandit
👍 1
Both B and D will address the requirement. For B you need to change Google limits and for D you can set the limit to yourself. I will go for the option that does not need any change at Google side.
gcppandit
👍 10
Selected: 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.
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.
CosminCiuc
👍 1
https://cloud.google.com/run/docs/configuring/max-instances#limits For instance using 1 CPU and 2GB memory, this maximum can be increased up to a limit of 1000 instances. The actual maximum limit depends on the region of the Cloud Run service and its CPU and memory configurations. If you want to specify a maximum number of instances greater than the maximum allowed in the region of the Cloud Run service, you must request a quota increase. I think answer B is the correct one.
skyblue07
👍 3
Selected: A
Additionally, "based on exact matches of a known set of attributes" points to Big Query. Bigtable is a key-value database.
gcppandit
👍 1
BiqQuery can not handle 500,000 concurrent requests. So you have to go for either B and D. Both can be used with some configuration or change in limits.
steghe
👍 2
With BigTable you can build the key with the concatenation of the "known set of attributes" and so the exact value is found easily
jay9114
👍 2
Selected: B
My reason for choosing Cloud Run? "Cloud Run only runs when requests come in, so you don't pay for time spent idling" https://dev.to/pcraig3/cloud-run-vs-app-engine-a-head-to-head-comparison-using-facts-and-science-1225
thamaster
👍 1
Selected: B
Cloud run is perfect to match high peak activity and scale to 0 to allow low cost when you don't need it.
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.
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.
CDL_Learner
👍 1
For Heavy Write Big Table is the Only Option . For Cost Saving , Cloud RUn is the correct Option . Hence B .
Mr_MIXER007
👍 1
Selected: B
B for me
megumin
👍 1
Selected: B
B is ok
Balaji_Sakthi
👍 1
Selected: B
i vote B. Real time is the key word of this question.
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
abhinav855
👍 3
The correct answer is D, with MIGs, you can reduce the workload to 0 as well whenever needed and it can better handled the workload compared to Cloud Run
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
6721sora
👍 7
Selected: 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.
n_nana
👍 1
Very good point to mentioned. Thanks for sharing
KyubiBlaze
👍 1
If you would consider that scenario, then bursts could be way above a single compute engine instance can handle too, hence what you say applies to both situations, you say 5000, I say it'll come at 100000 and compute engine will fail too. Hence your point becomes invalid, though it is logical, hence B is the right answer.
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.
Nirca
👍 3
Selected: B
B is the right one
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
elainexs
👍 3
Selected: B
B is good, as it supports scaling to zero, to concurrency requests. so meet req't of cost-saving.
Superr
👍 2
Selected: B
B because of low cost
JohnPi
👍 4
Selected: B
Container instance | Maximum number of container instances | 1000 | per service Request | Maximum number of concurrent requests | 1000 | per container instance 1000*1000 > 500000
gee1979
👍 1
great explanation!
gaojun
👍 2
Go for B cause "There will be periods where the web service will not receive any requests" and Cloud Run can scale down to zero
mkc110891
👍 3
Selected: 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
segkhachat
👍 1
The limit 1000 is set per instance, so having 500 instances may handle that.
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.
brvinod
👍 3
Selected: 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
ss909098
👍 3
Selected: B
Yes, it is B because low cost, and cloud Run can go to 0 instances
bhtay
👍 1
Selected: B
Cloud Run can scale down to zero.
muky31dec
👍 3
Selected: 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:
GARY1119
👍 1
B is correct. https://qwinix.io/blog/what-is-cloud-run/#:~:text=Powered%20by%20Knative%2C%20Cloud%20Run,a%20stateless%2C%20autoscaling%20HTTP%20service.&text=Cloud%20Run%20is%20a%20fully%20managed%20platform. Cloud Run will scale to 0 if no request come and cost effective.
ks100
👍 1
Selected: D
Compute Engine autoscaling will scale down when service not needed
santoshindia
👍 3
Selected: 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
pddddd
👍 2
and quote is 1000 cloud run instances => 1000 * 1000 = 1 000 000 reqs/s
santoshindia
👍 2
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
Fotofilico
👍 1
Selected: D
Infrastructure is the key!
joheri
👍 2
Selected: D
I don't think cloud run would scale upto 500K req per second. When max instance is 1000 and concurrency can't be 500 I suppose. D would be the right choice.
GauravLahoti
👍 1
Correct Anwer is B
ehgm
👍 2
Selected: B
The only reason D is the right choice is if "You are implementing the infrastructure for a web service on Google Cloud" means that it must create an infra and not user a truly serverless service.
simbu1299
👍 1
B is the correct answer
Andrea67
👍 1
I'm agree with the task "business wants to keep costs low" but also at beginning of the question is required the I'm implementing the infrastructure for the .... so could be correct D
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.
PhilipKoku
👍 1
Selected: B
Cloud Run and Big Table
anjuagrawal
👍 2
Should be B because there are times when no request. It would be cost effective to use Cloud Run instead of MIG
vincy2202
👍 1
B is the correct answer
jdr75
👍 2
B. Cloud Run and Cloud Bigtable Cloud run scales to 0 if no request, and Bigtable is the BEST ingesting data, and VERY GOOD searching with a "known set of attributes".
pakilodi
👍 4
Selected: B
B. Because cloud run can scale to zero and for such heavy loads, it needs bigtable
nqthien041292
👍 2
Selected: B
Vote B
TheCloudBoy77
👍 1
B - Cloud run can scalde down to zero when not used. BigTable instead of BigQuery as it involves realtime data.
danielfootc
👍 2
IMHO, I would choose B coz cloud run can scale to zero where for compute engine autoscaling managed instance, the min is one instance. https://cloud.google.com/run/docs/about-instance-autoscaling. Bigtable is definitely one of the options as it involves real time data.
J19G
👍 2
I think the best option is B
rottzy
👍 2
B web service can be defined in cloud run, turn it down when not reqd big numbers query - big table
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
tsiddique
👍 2
Cloud Run also can host web service in container. Hence B
Zuy01
👍 2
i think the answer is B, refer from this link: https://cloud.google.com/blog/topics/developers-practitioners/bigtable-vs-bigquery-whats-difference
amxexam
👍 2
A - as we need to query the data so we have a BigQuery Query interface, Bigtable we need to manually set an instance to help query. CE we will eliminate anyway.
pr2web
👍 1
Answer is A. From BigQuery docs in GCP. In addition, Bigquery costs will be while loading data and significantly lower than BigTable when not in use. So Cloud Run (which scales down to 0) and BQ are the correct response. "Maximum rows per second per project in the us and eu multi-regions — 500,000" https://cloud.google.com/bigquery/quotas#streaming_inserts
J19G
👍 2
Thanks for pointing it out, I would have choose BigQuery as well until I read your link, note 500,0000 limit is a total limit, there is an additionally limit to 100,000 rows per second per table. "In other words, the sum of rows per second streamed to all tables for a given project within a multi-region is limited to 500,000. Each table is additionally limited to 100,000 rows per second." https://cloud.google.com/bigquery/quotas#streaming_inserts
Manh
👍 1
it's B
moustickiller
👍 1
should be D, in my opinion cloud run can't host a listening service. it must be triggered one way or another. not very pertinent for a web service.
moustickiller
👍 1
sorry, it's late in the evening. Confuse with cloud function :-( let's go for B
dhamo_555
👍 1
A) seems to be correct fit. Cost low is achieved by cloud Run. Cloud big table plays well in combination with any of Bigdata tools than working alone. so BigQuery will be a good option here as the data is queried in real time
AnilKr
👍 3
I was thinking for 'A' but due to heavy writes probably better is Bigtable so 'B'.
J19G
👍 1
BigQuery won't work. "Each table is additionally limited to 100,000 rows per second." https://cloud.google.com/bigquery/quotas#streaming_inserts
poseidon24
👍 2
BigQuery streaming option fits with the requirement. "Maximum rows per second per project in the us and eu multi-regions — 500,000" https://cloud.google.com/bigquery/quotas#streaming_inserts
SSV
👍 1
I feel answer should be A. In Question it is mentioned low cost. If you use Bigtable then cost will be high. Big query also can handle real time data and it is of low cost. More over if they expect low latency then Big table is right option but here they have not mentioned that so we can use bigquery.
Linus11
👍 2
Low cost part is done by Cloud Run. High read / write = Bigtable. Big query is needed when analysis is required.
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
hrosmendez
👍 1
I agree that BigTable is the correct choice. However, I can not imagine how we can use Cloud Run; it is serverless. For this reason, option D makes sense to me.
victory108
👍 6
B. Cloud Run and Cloud Bigtable
JeffClarke111
👍 4
B is ok
MamthaSJ
👍 16
B is correct answer.
muhasinem
👍 3
B is correct Answer: Cloud Run - Cost saving during idle time Big Table : Heavy writes
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
Linus11
👍 1
It is web service. and 5 lakh request per second. Points to load balancing may be needed. Managed instance group will be needed. Cloud Run not sufficient.
poseidon24
👍 1
Agree "queried, based on exact matches of a known set of attributes", this is more like SQL statements. BigTable we will need to build the keys using those attributes to have a good performance when querying those.
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")
hitmax87
👍 1
Incorrect, BigQuery perfectly works with heavy write loads. The choice depends on operations and data type
kshlgpt
👍 1
But cloud run can't support 50,000 request per second. Even cloud run 2nd gen supports 1000 requests per second. B is eliminated.
AmitRBS
👍 4
B. Agree. Additionally data need to store now so use Bigtable as question is not for analysing or data Analytics etc
zanfo
👍 2
the correct is B
pakilodi
👍 21
Not only: occasionally there will be no requests. so Cloud Run will scale to zero
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...
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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.
Related Analysis
Practice All PCA Questions
Access 81 questions with complete answers and detailed explanations.
View Full PCA Practice Test →