An architect is designing a Disaster Recovery (DR) plan for a global application that requires an active-active setup across multiple regions…

Cloud Spanner with a multi-region configuration is the only solution that meets all the requirements. It is a globally distributed, relational database service designed for active-active architectures that require horizontal scalability and strong transactional consistency across regions. Its ability to handle synchronous replication with external consistency ensures that data written to any region is immediately available and consistent in all other configured regions. This directly addresses the need for concurrent writes with low latency and high consistency for a global, mission-critical application.

A. Cloud Firestore with eventual consistency: This option is incorrect because its multi-region replication model is eventually consistent, which violates the strict requirement for high consistency for concurrent writes.

C. Cloud SQL Read Replica with asynchronous replication: This creates an active-passive architecture for writes. Only the primary instance can handle write operations, failing the active-active requirement. Asynchronous replication also introduces data lag.

D. BigQuery: BigQuery is an enterprise data warehouse designed for large-scale analytics (OLAP), not a transactional database (OLTP) suitable for low-latency application reads and writes.

1. Google Cloud Documentation - Cloud Spanner, "Multi-region configurations": "Multi-region configurations enable you to replicate your database's data in multiple regions... This enables you to have low-latency reads and writes from multiple locations across the globe... Spanner maintains synchronous replication and strong consistency in multi-region configurations."

Source: Google Cloud Documentation, Cloud Spanner, "Instances", Section: "Multi-region configurations".

2. Google Cloud Documentation - Cloud Spanner, "Transactions": "Cloud Spanner offers external consistency, which is a stronger guarantee than 'strong consistency'... External consistency guarantees that Spanner executes transactions in a way that is indistinguishable from a system in which the transactions are executed serially."

Source: Google Cloud Documentation, Cloud Spanner, "Transactions", Section: "Consistency".

3. Google Cloud Documentation - Cloud Firestore, "Choose a database: Cloud Firestore or Cloud SQL": "Cloud Firestore has an eventually consistent storage layer... This means that a read operation might not see the result of a very recent write operation."

Source: Google Cloud Documentation, Cloud Firestore, "Documentation", Section: "Choose a database".

4. Google Cloud Documentation - Cloud SQL, "Replication options": "The primary instance handles all write operations. The read replica handles only read requests." This confirms the active-passive model for writes.

Source: Google Cloud Documentation, Cloud SQL for MySQL, "Replication", Section: "Replication options".

5. Corbett, J. C., et al. (2012). "Spanner: Google's Globally-Distributed Database." In Proceedings of the 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI '12). This foundational, peer-reviewed paper describes Spanner's architecture, stating, "Spanner is designed to support global, externally consistent transactions." (Section 1: Introduction).

DOI: Available through ACM Digital Library or USENIX archives. A public version is often hosted on Google Research publications.