An enterprise is architecting a globally distributed mobile platform deployed across the United States, Europe, and Asia. The application encompasses two distinct operational data paths: Social Activity Stream: Tracks user interactions, presence state, and social reaction counters (such as post likes and upvotes). This workload requires ultra-low latency, multi-continent write accessibility, and maximum availability ($A$) even during cross-continent network partitions ($P$), where temporary stale reads are acceptable. Billing and Wallet Ledger: Processes financial token top-ups, checkout payments, and user balances. This workload strictly mandates ACID compliance, global transactional integrity, and strong consistency ($C$) to prevent double-spending, even if network partitions introduce latency or reject writes to maintain consistency ($CP$). According to CAP theorem principles and Google Cloud database characteristics, which architectural design correctly implements these requirements?

Implement a distributed NoSQL database (such as Firestore/Datastore) utilizing an eventual consistency model for the Social Activity Stream, and deploy a multi-region Cloud Spanner instance with synchronous replication for the Billing and Wallet Ledger.: ### What the Solution Is This architecture leverages a specialized multi-database pattern combining a **non-relational distributed NoSQL database** configured for **eventual consistency** with **Cloud Spanner**, Google Cloud's fully managed, globally distributed, horizontally scalable, and strongly consistent relational database. ### How it Meets the Social Activity Stream Requirements - **Availability and Partition Tolerance (AP focus)**: Social feeds, likes, and buddy presence operate on non-relational entities where high throughput and regional survivability supersede immediate synchronization. - **Eventual Consistency Trade-off**: Replicas remain accessible for local reads and writes, allowing replicas to temporarily diverge during high load or cross-region network splits while eventually converging to the last updated state. ### How it Meets the Billing and Wallet Ledger Requirements - **Strict ACID Compliance and Strong Consistency (CP focus)**: Multi-region **Cloud Spanner** uses **synchronous replication** via the Paxos consensus algorithm and TrueTime hardware clocks to guarantee external consistency (linearizability) and serializable transactions globally. - **Guaranteed Ledger Integrity**: By prioritizing global **strong consistency** over unconstrained local availability during severe network partition events, Cloud Spanner prevents critical financial phenomena such as double-spending and ledger divergence. ### Key Advantages and Capabilities - **Optimized Latency Profiles**: High-volume, loss-tolerant social interactions avoid expensive cross-continental locking mechanisms, keeping latency minimal. - **Zero Transaction Anomalies**: Financial transactions strictly observe atomic commit protocols across geographically separated regions. - **Selective Consistency**: Matches data access patterns directly to business criticality, avoiding over-engineering non-critical telemetry while safeguarding financial assets. - **Horizontal Scalability**: Both storage layers scale horizontally without requiring manual sharding or custom replication logic. ### Why This Is Optimal The **CAP theorem** dictates that a distributed system cannot simultaneously achieve Consistency, Availability, and Partition Tolerance under all network conditions. Dividing workloads across an **AP-leaning eventually consistent NoSQL data store** and a **CP-leaning strongly consistent distributed engine (Cloud Spanner)** ensures optimal performance and correctness for each domain.

Cap Theorem Distributed Data Architecture Tradeoffs | professional-cloud-data-engineer

Cap Theorem Distributed Data Architecture Tradeoffs

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise is architecting a globally distributed mobile platform deployed across the United States, Europe, and Asia. The application encompasses two distinct operational data paths:

Social Activity Stream: Tracks user interactions, presence state, and social reaction counters (such as post likes and upvotes). This workload requires ultra-low latency, multi-continent write accessibility, and maximum availability ($A$) even during cross-continent network partitions ($P$), where temporary stale reads are acceptable.
Billing and Wallet Ledger: Processes financial token top-ups, checkout payments, and user balances. This workload strictly mandates ACID compliance, global transactional integrity, and strong consistency ($C$) to prevent double-spending, even if network partitions introduce latency or reject writes to maintain consistency ($CP$).

According to CAP theorem principles and Google Cloud database characteristics, which architectural design correctly implements these requirements?

Deploy Cloud SQL with cross-region asynchronous read replicas for both the Social Activity Stream and the Billing and Wallet Ledger workloads.

Configure a single multi-region Cloud Spanner instance using strict synchronous read-write transactions for all social reactions, presence indicators, and financial ledger updates.

Implement a distributed NoSQL database (such as Firestore/Datastore) utilizing an eventual consistency model for the Social Activity Stream, and deploy a multi-region Cloud Spanner instance with synchronous replication for the Billing and Wallet Ledger.

Store all social stream events and billing transactions in regional Cloud Storage buckets fronted by Cloud CDN with stale-while-revalidate caching headers.

Professional Cloud Data Engineer

Cap Theorem Distributed Data Architecture Tradeoffs

Related questions