Design scalable and highly available cloud database solutions
This domain tests whether you can select the right Google Cloud database for a workload and design it to survive zone or region failure while scaling reads and writes. The exam favors concrete trade-offs: consistency model, write throughput, latency, SLA, and operational burden.
Match the engine to the workload
- Cloud SQL (MySQL, PostgreSQL, SQL Server) for lift-and-shift relational workloads that fit a single primary; scale reads with replicas, not writes.
- Spanner for horizontal write scale with strong consistency and global transactions; choose regional or multi-region configurations.
- Bigtable for high-throughput, low-latency key-range access; design row keys to avoid hotspots.
- Firestore for document workloads with automatic multi-region replication and strong consistency for single-document reads.
- BigQuery for analytics, not OLTP point writes.
HA is not the same as read scaling
Cloud SQL regional HA uses a standby in a second zone and performs automatic failover, but existing connections drop. Read replicas serve read traffic and can be cross-region; they are not automatic failover targets. Cloud SQL Enterprise Plus carries a 99.99% SLA versus 99.95% for Enterprise. Spanner regional is 99.99%; multi-region is 99.999%. Bigtable replication uses multiple clusters, not a single-cluster zone failover. Firestore location type is chosen at creation and cannot be changed later.
Worked example
A global inventory service needs strong consistency, 99.999% availability, and write-heavy traffic across continents. Choose Spanner multi-region with a leader region for writes and read-only regions for local reads. Model line items as interleaved tables so parent and child rows co-locate, and choose a high-cardinality first key column that is not monotonically increasing to avoid hotspots. Do not add read replicas to Cloud SQL and call it global HA; that does not provide automatic cross-region failover.
Traps that cost marks
Assuming read replicas fail over automatically; treating Cloud SQL HA as write scaling; choosing Spanner regional when the requirement explicitly says 99.999%; using Bigtable with sequential row keys such as timestamps; and forgetting that Firestore multi-region selection is permanent.
Key rules
Design for failure domain first, then scale. Use HA configuration for availability and replicas or sharding for capacity. Validate the SLA number against the stated requirement before choosing the engine.