Choosing Cloud Spanner for ACID Compliant Banking Transactions

PDE By islever Editorial Last updated

Selecting storage systems. Monitoring and troubleshooting processes.

Short answer

B Store transaction in Cloud Spanner and use locking read-write transactions to ensure ACID compliance and SQL access for global banking operations.

Question

You work for a large bank that operates in locations throughout North America. You are setting up a data storage system that will handle bank account
transactions. You require ACID compliance and the ability to access data with SQL. Which solution is appropriate?
  1. Store transaction data in Cloud Spanner. Enable stale reads to reduce latency.
  2. Store transaction in Cloud Spanner. Use locking read-write transactions. Correct Answer
  3. Store transaction data in BigQuery. Disabled the query cache to ensure consistency.
  4. Store transaction data in Cloud SQL. Use a federated query BigQuery for analysis.

Key Takeaways

The main trap is confusing OLTP needs with OLAP tools like BigQuery or underestimating the scalability benefits of Spanner over Cloud SQL for large global banks.

This question identifies Cloud Spanner with locking read-write transactions as the correct solution for storing bank account transactions requiring ACID compliance and SQL access.

Common mistake: Candidates often choose Cloud SQL (D) because it is a familiar relational database with ACID support, but they miss the implication of 'large bank' and 'North America' which favors Spanner's global distributed architecture.

Expert Analysis

The scenario requires a data storage system for bank account transactions that supports SQL access and guarantees ACID compliance. The key constraints are the need for strong consistency (ACID) and the scale implied by a "large bank" operating across North America.

Cloud Spanner is a globally distributed, strongly consistent database service that provides horizontal scalability while maintaining relational integrity and standard SQL support. It natively ensures ACID transactions, which is critical for financial data where atomicity and isolation are non-negotiable. For transactional workloads requiring strict consistency, locking read-write transactions are the appropriate mechanism to ensure that concurrent updates do not violate data integrity. This aligns with option B.

Option A suggests using stale reads in Cloud Spanner. Stale reads allow applications to trade off some consistency for lower latency by reading data from a past timestamp. In a banking context involving account transactions, accepting stale or inconsistent data violates the requirement for ACID compliance and could lead to significant financial errors. Therefore, this option is incorrect.

Option C proposes BigQuery. While BigQuery is a powerful data warehouse, it is designed for analytical processing (OLAP) rather than transactional processing (OLTP). It does not support row-level locking or real-time ACID transactions suitable for high-frequency banking operations. Disabling the query cache does not transform it into a transactional database.

Option D suggests Cloud SQL. Cloud SQL is a relational database service that supports SQL and ACID transactions. However, it is vertically scalable and lacks the native global distribution of Spanner. While it technically meets the ACID and SQL requirements, the prompt's emphasis on a "large bank" operating throughout North America often implies a need for horizontal scalability and low-latency global access, which points toward Spanner as the more robust enterprise solution for such scale. Furthermore, community feedback heavily favors Spanner due to its specific design for globally distributed ACID workloads, distinguishing it from the regional nature of standard Cloud SQL instances unless explicitly configured for higher availability at greater complexity. Between B and D, B is the stronger answer for a globally distributed, large-scale banking application requiring strict ACID guarantees.

Official Reference

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

Exam Strategy

When evaluating database solutions for transactional workloads, always distinguish between OLTP (Online Transaction Processing) and OLAP (Online Analytical Processing) requirements. Use keywords like 'ACID', 'transaction', and 'banking' to eliminate analytical stores like BigQuery. Then, assess scale: if 'global', 'distributed', or 'large scale' is mentioned alongside ACID, prioritize Cloud Spanner over Cloud SQL due to its horizontal scaling capabilities.

Frequently Asked Questions

Why not Cloud SQL for banking transactions?

Cloud SQL supports ACID and SQL, but it is primarily vertically scalable. For a 'large bank' with global operations, Cloud Spanner offers superior horizontal scalability and global distribution while maintaining strong consistency.

What is a locking read-write transaction in Spanner?

It is a transaction type that ensures linearizable consistency by locking rows during the write phase, preventing other transactions from modifying the same data until the transaction completes, thus guaranteeing ACID properties.

Can BigQuery handle bank account transactions?

No. BigQuery is an OLAP data warehouse optimized for analytics queries, not OLTP transactional systems. It does not support the row-level locking and real-time consistency required for individual account transactions.

More PDE FAQ →

Community Votes

B
56%
D
38%
C
6%

56% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

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

  1. Jay_Krish 👍 14
    I wonder if you understood the meaning of ACID. This is an inherent property of any relational DB. Cloud SQL is fully ACID complaint
  2. devaid 👍 12 Answered B
    I'd say B as the documentation primarily says ACID compliance for Spanner, not Cloud SQL. https://cloud.google.com/blog/topics/developers-practitioners/your-google-cloud-database-options-explained Also, spanner supports read-write transactions for use cases, as handling bank transactions: https://cloud.google.com/spanner/docs/transactions#read-write_transactions
  3. juliobs 👍 12 Answered B
    "locations throughout North America" implies multi-region (northamerica-northeast1, us-central1, us-south1, us-west4, us-east5, etc.) Cloud SQL can only do read replicas in other regions.
  4. jkhong 👍 6 Answered B
    The question is hinting a requirement for global consistency, i.e. being available for NA region, which does not just include US but also Mexico, Argentina etc. Large bank = priority over consistency over read-write
  5. cajica 👍 5
    This is definitely a tricky question because both B and D are "appropriate" as the question suggests, of course we can make assumptions with the "large bank" sentence but there are other questions here where making assumptions is not accepted by the community so I wonder when can we make assumptions and when we can't. I think the real problem here is the ambiguous question. This is one of the few questions where the community accept that both (B and D) answers are appropriate but some comments (and I agree) argue the BEST approach is B. I really think some questions can be written in a better and non-ambiguous way, it's just about thinking a little bit more and not conforming when a poor spelling.
Show 25 more comments
  1. desertlotus1211 👍 5
    Argentina is South America...
  2. MaxNRG 👍 4 Answered B
    B. Store transaction in Cloud Spanner. Use locking read-write transactions. Since the banking transaction system requires ACID compliance and SQL access to the data, Cloud Spanner is the most appropriate solution. Unlike Cloud SQL, Cloud Spanner natively provides ACID transactions and horizontal scalability. Enabling stale reads in Spanner (option A) would reduce data consistency, violating the ACID compliance requirement of banking transactions. BigQuery (option C) does not natively support ACID transactions or SQL writes which are necessary for a banking transactions system. Cloud SQL (option D) provides ACID compliance but does not scale horizontally like Cloud Spanner can to handle large transaction volumes. By using Cloud Spanner and specifically locking read-write transactions, ACID compliance is ensured while providing fast, horizontally scalable SQL processing of banking transactions.
  3. FP77 👍 4
    Read replicas are enough to make Cloud SQL work as a multi-region service. That's not the point. The point is that the answer introduces the use of Bigquery when it's not needed for the use case. That's why B is right.
  4. barnac1es 👍 3 Answered B
    ACID Compliance: Cloud Spanner is a globally distributed, strongly consistent database service that offers ACID compliance, making it a suitable choice for handling bank account transactions where data consistency and integrity are crucial. SQL Access: Cloud Spanner supports SQL queries, which align with your requirement to access data with SQL. You can use standard SQL to interact with the data stored in Cloud Spanner. Locking Read-Write Transactions: Cloud Spanner allows you to perform locking read-write transactions, ensuring that transactions are executed in a serializable and consistent manner. This is essential for financial transactions to prevent conflicts and maintain data integrity.
  5. NicolasN 👍 2 Answered D
    [A] No - Stale reads not accepted for bank account transactions. "A stale read is read at a timestamp in the past. If your application is latency sensitive but tolerant of stale data, then stale reads can provide performance benefits." [B] Yes - Fulfills all requirements [C] No - BigQuery is ACID-compliant, but it is too much to use it for such a case (mainly a CRUD app) [D] Yes+ - Fulfills all requirements. The BigQuery part may seem redundant, but it states a true fact that doesn't violate the "access data with SQL" requirement. So, when SQL Cloud and SQL Spanner fit both, there is no reason to prefer the second. And the question doesn't mention any obvious fact for which should we prefer the expensive SQL Spanner: - We don't know if we have to deal with a big amount of data and thousands of writes per second. - We don't know the database size. - There is no need for multi-regional writes that would exclude SQL Cloud as an alternative. Is it a coincidence that the question limits the problem to the single region of North America?
  6. AWSandeep 👍 2 Answered D
    D. Store transaction data in Cloud SQL. Use a federated query BigQuery for analysis. Cloud SQL or Cloud Spanner is required for ACID-based transactions in real-time. BigQuery cannot be used as table & row-level locking is required. BigQuery federated queries can directly access operational databased for ad-hoc analysis.
  7. musumusu 👍 2
    Answer B: Spanner It's incomplete question, what do you assume by large bank, until we are not sure about size and scale. Region is north america, that can be managed by cloud sql. but i am going for spanner, as its large bank and transaction data.
  8. YorelNation 👍 2 Answered D
    D no indication for multi region availability or very big volume of data. so no spanner.
  9. musumusu 👍 2
    Answer B: locking read-write = for data accuracy state read = for speed up or latency
  10. adarifian 👍 2
    there's no requirement for analysis, though
  11. Mcloudgirl 👍 2
    + CloudSQL is cheaper than Spanner
  12. MounicaN 👍 2
    why not spanner?
  13. Adswerve 👍 1 Answered D
    I initially selected B. However, it might be D. https://cloud.google.com/blog/topics/developers-practitioners/your-google-cloud-database-options-explained Cloud Spanner: Cloud Spanner is an enterprise-grade, globally-distributed, and strongly-consistent database that offers up to 99.999% availability, built specifically to combine the benefits of relational database structure with non-relational horizontal scale. It is a unique database that combines ACID transactions, SQL queries, and relational structure with the scalability that you typically associate with non-relational or NoSQL databases. As a result, Spanner is best used for applications such as gaming, payment solutions, global financial ledgers, retail banking and inventory management that require ability to scale limitlessly with strong-consistency and high-availability.
  14. carbonscave 👍 1 Answered B
    Why B is correct Global Relational Scale: Cloud Spanner is Google Cloud's fully managed, horizontally scalable relational database. It is structurally designed for massive, multi-regional or continental scale (like a large bank operating across North America) while still maintaining strict relational schemas and standard ANSI SQL access. ACID Compliance via Locking: For financial transactions, you cannot afford race conditions (e.g., two concurrent requests attempting to withdraw the last $100 from an account). Cloud Spanner uses pessimistic locking during read-write transactions to ensure strict ACID compliance (Atomicity, Consistency, Isolation, Durability) and strong global consistency.
  15. NeoNitin 👍 1
    B. Store transaction data in Cloud Spanner. Use locking read-write transactions. Here's why: ACID Compliance: ACID stands for Atomicity, Consistency, Isolation, and Durability. Cloud Spanner is a fully managed, globally distributed database that provides strong consistency and ACID compliance. This ensures that bank account transactions are processed reliably and accurately, avoiding issues like data corruption or incomplete transactions. Ability to access data with SQL: Cloud Spanner supports SQL, which allows you to perform standard SQL queries on the data. This means that you can use familiar SQL commands to access, retrieve, and manipulate transaction data easily.
  16. NicolasN 👍 1 Answered B
    Finally, it's [B]. There is no measurable requirement that rules out [D] (Cloud SQL) and this fact made me to select it as a preferrable answer. But since we are talking about a large bank (which normally implies massive reads/writes per sec.) and nobody has posed any cost limitation, in a real case I would definitely prefer the advantages of Spanner.
  17. ducc 👍 1
    C. Store transaction data in BigQuery. Disabled the query cache to ensure consistency. It is storage system, not a processing system, so Bigquery is the choice Here is my short-cut for choosing: Storage system (or even "store transaction") -> Big Query Process, consistency -> SQL (if global/ scale horizontally -> Spanner)
  18. mattab1627 👍 1
    Surely its B, transactional data at a large US based bank would surely be massive in size and probably too much for CloudSQL? There is also no mention of a requirement for analytics
  19. SuperVee 👍 1
    Also, correct me if I am wrong, Bigquery cannot query Cloud SQL directly, only when Cloud SQL is exported into GCS, then BQ can connect to GCS using federated queries.
  20. Aman47 👍 1 Answered B
    Spanner is an enterprise level resource which Banks require, Cloud SQL is limited to 30TB of storage. And Banking transactions should be read write locked.
  21. NicolasN 👍 1
    I changed my mind to [B] since I underestimated the given of a "large bank" where the cost difference for a single region Spanner wouldn't matter.
  22. nwk 👍 1
    Why not B? There is no requirement for analysis and hence bq. https://cloud.google.com/spanner/docs/transactions#read-write_transactions
  23. cloudmon 👍 1 Answered B
    I'd go for B. The only other somewhat valid option is D, but there's no requirement for analytics in the question.
  24. ducc 👍 1 Answered D
    D is correct Because ACID = (atomicity, consistency, isolation, and durability) Sorry for other false explanation
  25. ckanaar 👍 1
    Good catch, definetely Spanner in that case.

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.

How to establish consistent BigQuery spend?

S-grade

Triggering Airflow DAGs Reactively in Private Cloud Composer

S-grade

Bigtable Row Key Design for Time-Series Data

S-grade

Monitoring Cloud Bigtable for Cluster Scaling Decisions

S-grade

← Back to PDE Study Guide