Choosing Storage for High-Volume Clickstream Data

PCA By islever Editorial Last updated

Designing network, storage, and compute resources. Configuring individual storage systems.

Short answer

B Google Cloud Bigtable ingests the 6,000-clicks-per-minute stream with 8,500-per-second bursts and serves the teams' future analysis.

Question

You have been asked to select the storage system for the click-data of your company's large portfolio of websites. This data is streamed in from a custom website
analytics package at a typical rate of 6,000 clicks per minute. With bursts of up to 8,500 clicks per second. It must have been stored for future analysis by your
data science and user experience teams.
Which storage infrastructure should you choose?
  1. Google Cloud SQL
  2. Google Cloud Bigtable Correct Answer
  3. Google Cloud Storage
  4. Google Cloud Datastore

Key Takeaways

The test is matching a very high write-rate event stream destined for analytics to the right storage class, and the trap is picking Cloud Storage (object, batch-oriented) simply because the data is 'stored for later analysis' rather than served live.

This Google Cloud Professional Cloud Architect question asks which storage infrastructure should ingest a continuous clickstream (6,000 clicks per minute with bursts up to 8,500 clicks per second) and hold it for later data science and UX analysis. The correct choice is Google Cloud Bigtable, the managed wide-column NoSQL database purpose-built for sustained high-throughput event writes and time-series/clickstream analytics at scale.

Common mistake: The most common wrong answer is C, Google Cloud Storage: learners reason that because the data is only needed for future (not real-time) analysis, cheap object storage is sufficient. That ignores that a stream of thousands of individual click events per second needs low-latency, row-level append and query semantics — object storage writes are metadata-heavy, latency-bound, and a poor fit for a continuous per-event feed.

Expert Analysis

Why the Answer Is Correct

Google Cloud Bigtable (B) is a fully managed wide-column NoSQL database explicitly recommended by Google for clickstream data, IoT ingestion, and time-series/event workloads with heavy write throughput. It scales horizontally by node, absorbs sustained ingestion in the thousands-of-writes-per-second range plus burst load, and keeps per-row read latency low for later analytical scans. Because the click data must be retained and queried by the data science and UX teams, Bigtable's model of sparse, time-ordered event rows keyed for range scans fits perfectly. Google's own use-case documentation lists clickstream and behavioral analytics as a flagship Bigtable workload, which is exactly what this scenario describes.

Why the Other Options Are Wrong

Cloud Storage (C) is object storage: it is excellent for files, images, and batch exports, but it offers no row-level updates, has no database engine, and imposes per-request/per-operation overhead and throughput ceilings that make it unsuitable for a live per-click ingest stream. (The community claim that Cloud Storage caps at 1,000 writes per second is now an outdated figure, but the architectural mismatch still stands.) Cloud SQL (A) is a managed relational OLTP engine — vertical write throughput, connection limits, and storage growth ceilings make it a poor choice for millions of rapidly accumulating event rows, and it is not an analytics store. Datastore/DFirestore in Datastore mode (D) targets entity/document workloads with transactional semantics and strong per-entity contention and throughput constraints, not bulk high-rate time-series ingestion at 8,500 events per second.

Community Comment Notes

The community is heavily split toward B: victory108, jeff001, fff2e69, Ekramy_Elnaggar, omermahgoub, army234 and doumx all argue Bigtable, with fff2e69 noting it "is well-suited for handling high-throughput, low-latency workloads like clickstream data." Jambalaja cites a Cloud Storage request-rate limit to rule out C, though that specific figure is outdated — the deeper reason C fails is the object-storage data model, not one number. On the other side, SanderA objects that "the data is stored for later analysis only, not for live reporting" and upliftinghut likewise picks C because "the need for analysis is not urgent" — both confuse query urgency with ingest mechanics: the data still has to be written per event as it streams in, and that requirement alone eliminates object storage.

Official Reference

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

Exam Strategy

In PCA storage-selection items, always separate the ingest path from the serving path: a stream of thousands of events per second needs a write-optimized NoSQL/time-series store (Bigtable), regardless of whether results are read in real time. Read the workload verbs — 'streamed,' 'clicks per second,' 'for future analysis' — and map them to Bigtable's documented clickstream use case rather than to object or relational storage.

Frequently Asked Questions

Why not Google Cloud Storage if the click data is only stored for later analysis?

Object storage has no rows or query engine and is built for batch-oriented file access, not a continuous per-click ingest stream. Bigtable handles the event-rate write volume and still supports the later analytical reads.

Could Google Cloud SQL absorb 8,500 clicks per second of write traffic?

No — Cloud SQL is a relational OLTP service whose write throughput, connection count, and storage growth scale vertically and saturate far below a sustained event stream of this size.

More PCA FAQ →

Discussion 55 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 55

  1. jeff001 👍 10
    B, Bigtable due to the IoT like requirements
  2. Jambalaja 👍 9
    B is right. C is wrong, because Cloud Storage has IO write limits of 1000 writes / second. See source: https://cloud.google.com/storage/docs/request-rate#auto-scaling
  3. omermahgoub 👍 4
    For storing click-data that is streamed in at a rate of 6,000 clicks per minute, with bursts of up to 8,500 clicks per second, and that needs to be stored for future analysis by your data science and user experience teams, you should consider using a scalable, high-performance, and low-latency NoSQL database such as Google Cloud Bigtable, option B. Google Cloud Bigtable is a fully managed, high-performance NoSQL database service that is designed to handle large volumes of structured data with low latency. It is well-suited for storing high-velocity data streams and can scale to handle millions of reads and writes per second. Option A: Google Cloud SQL, option C: Google Cloud Storage, and option D: Google Cloud Datastore, would not be suitable for this use case, as they are not designed to handle high-velocity data streams at this scale.
  4. Ekramy_Elnaggar 👍 4 Answered B
    1. High throughput for clickstream data: Bigtable is a NoSQL database designed for high write throughput, making it ideal for handling the continuous stream of click data with bursts up to 8,500 clicks per second. 2. Scalability: Bigtable is highly scalable, allowing you to handle increasing data volumes as your website portfolio grows. 3. Low latency: Bigtable provides low latency data access, which is important for real-time analysis and reporting on clickstream data. 4. Integration with BigQuery: Bigtable integrates well with BigQuery, enabling your data science team to perform complex analysis and generate insights from the clickstream data.
  5. fff2e69 👍 4 Answered B
    Google Cloud Bigtable is well-suited for handling high-throughput, low-latency workloads like clickstream data. It is optimized for analytics on time-series and event data at scale, and it supports high write rates, with the capacity to handle thousands of writes per second. This makes it ideal for storing large volumes of clickstream data with bursts, ensuring data is available for analysis by data science and user experience teams.
Show 25 more comments
  1. SanderA 👍 4
    The data is stored for later analysis only, not for live reporting, So why go with BigTable? I would say go for Cloud Storage. C
  2. doumx 👍 4
    B for sure cause : NoSQL and hight volume transaction
  3. army234 👍 4
    Nope, B is correct.
  4. Pipoca 👍 3
    Tricky question. Usually google recommends Bigtable for IoT. But none of the requirements rule out Datastore as far as I could find. For safety I would go with Bigtable, as bursts of 8500 writes per second have the potencial to disrupt operations in Datastore. If someone can find documentation on this it would be much appreciated.
  5. kuboraam 👍 3
    They didnt say anything about cost savings in the question, so BigTable is the clear solution. Also they mention bursts of around 8500 clicks per second. Cloud Storage supports a max of only about 1000 writes per second. https://cloud.google.com/storage/docs/request-rate
  6. AashishAggarwal2000 👍 3
    B. Google Cloud Bigtable because it supports : a) the low latency + high throughput workloads are required in this use-case to support 8500 clicks events per second. b) the OLAP use case to integrate and analyse this data with various ML and data-science services.
  7. rsamant 👍 3
    it should be C for real time streaming also . IO can be throttled using pubsub or dataflow while writing data justifying bigtable cost for later analysis is not justified . look @ below diagram from GCS Page https://cloud.google.com/storage#section-6
  8. penelop 👍 3
    What are you talking about? Cloud storage is being used as a data lake there, and is being queried by BigQuery. Click-streams are not SQL, therefore this diagram is not applicable at all. You need a non-SQL solution. Hence B.
  9. guid1984 👍 3
    Answer is C, if you read below two articles then its clear https://cloud.google.com/solutions/build-a-data-lake-on-gcp https://cloud.google.com/solutions/architecture/optimized-large-scale-analytics-ingestion
  10. StelSen 👍 3
    Answer is B. This links provides nice explanation. https://stackoverflow.com/questions/53489250/price-aside-why-ever-choose-google-cloud-bigtable-over-google-cloud-datastore
  11. alekonko 👍 3 Answered B
    Bigtable is a high-perf NoSQL db service that handle large volumes of structured data with low latency
  12. upliftinghut 👍 3 Answered C
    Big table if it needs real time but here the need for analysis is not urgent => Google cloud storage.
  13. Moss2011 👍 3 Answered B
    For the amount of clicks per second the only storage that supports that is BigTable
  14. zr79 👍 3
    Bigtable for a high volume of writes. 8500 clicks per sec
  15. i_am_robot 👍 2
    B. Google Cloud Bigtable Google Cloud Bigtable is a scalable, high-performance NoSQL database that is well-suited for storing large amounts of data with low latency. It is designed for high-throughput workloads such as streaming data, and is able to handle bursts of up to millions of reads and writes per second. Given the high volume of click data that needs to be stored and the requirement for low latency, Google Cloud Bigtable would be a good choice for storing the data. It is able to handle the high rate of incoming data and provide fast access to the data for analysis by the data science and user experience teams. Google Cloud SQL is a fully-managed relational database service, and may not be the best choice for storing high-volume streaming data. Google Cloud Storage is an object storage service, and may not provide the necessary performance for storing and querying large amounts of data in real-time. Google Cloud Datastore is a NoSQL document database, and while it may be suitable for storing large amounts of data, it may not provide the necessary performance for handling high volumes of streaming data.
  16. Mont 👍 2
    Data is in IoT Nature and Big Table is the right choice. Cloud SQL is mainly for OLTP (Transactional, CRUD) not for taking and storing streaming data. It does not have the scalability and elasticity to absorb this amount of data in real-time. SO the answer is without any doubt Big Table B.
  17. Shabje 👍 2
    Since this is required only for future analysis, won’t we prefer to land it on the less expensive Cloud Datastore, instead of BigTable whose cost is not justified here.
  18. haroldbenites 👍 2
    Go for C. Analytics event - Cold Path: https://cloud.google.com/architecture/optimized-large-scale-analytics-ingestion
  19. Q_Review 👍 2
    The question references "Analytics" a large quantity of data. It's not a trick question; Bigtable is the answer. B.
  20. gfhbox0083 👍 2
    B, for sure. BigTable for IOT https://cloud.google.com/solutions/iot-overview
  21. belly265 👍 2
    Ans B -Google cloud big table can only handle this
  22. AD2AD4 👍 2
    Final Decision to go with Option B
  23. holerina 👍 2
    for analystics choose big table
  24. vincy2202 👍 2
    Answer is B
  25. Ziegler 👍 2
    B is rght

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