Design, migrate, and run scalable, highly available databases on Google Cloud across relational and NoSQL services, and track your readiness for the Professional Cloud Database Engineer exam.
Prepare and test your skills
Prepare and test your skills
Evaluate High Availability and Disaster Recovery Metrics is the comparison of how fast a database recovers and how much data it can lose across zonal, regional, and multi-regional designs. The two core metrics are Recovery Time Objective (RTO), the time until the system is running again after a disaster, and Recovery Point Objective (RPO), the amount of data loss that can be tolerated. In Google Cloud, RTO and RPO are defined by the scope of loss, meaning a zone outage, a region outage, or a multi-region outage, rather than by the cause. Wider geographic distribution places copies of data and compute on different sides of those failure boundaries, which directly improves RTO and RPO.
Recovery Time Objective (RTO) and Recovery Point Objective (RPO) turn business needs into choices about zonal, regional, and multi-regional configurations. RTO measures downtime after a disaster, while RPO measures how much committed data can be lost. Business-critical operations that must meet strict RTO and RPO can depend only on data plane components that continuously process operations, not on management plane operations such as a virtual machine creation API or an identity permission update. If a critical operation needs the management plane during an outage, recovery stalls even when the data is still intact.
A zonal deployment strategy hosts resources inside a single zone, so an interruption in that zone can affect all resources in that zone. Compute Engine (opens in a new tab) virtual machines and Persistent Disk are the main zonal resources, with a platform availability target of 99.9% and an RTO of hours or days after a zone outage. A zone outage does not always make every resource unavailable, but the zone defines the expected boundary of the incident and recovery requires waiting for resolution or restoring elsewhere. Correlated outages across multiple zones in one region can still occur, at which point regional outage planning applies.
To survive a zone failure with zonal resources, the team must design, build, and test its own failover between zones:
A regional deployment strategy redundantly deploys resources across multiple zones in one region, so the resource automatically serves from another zone if one zone is interrupted. Cloud SQL (opens in a new tab) configured for high availability, regional managed instance groups, regional Cloud Storage buckets, and regional Spanner instances are examples of regional resources with a platform availability target of 99.99%. That target still allows nearly an hour of downtime per year, so critical applications need a multi-region disaster recovery plan even when they use regional resources. A failure in one zone is unlikely to affect other zones, and RTO is near zero when data is replicated synchronously between primary and standby copies.
Regional protection stops at the region boundary, so a regional outage affecting more than one zone makes a purely regional database unavailable. Recovery then depends on a passive replica in a different region that is activated during the outage, with RTO and RPO determined by how current that replica is. A Cloud SQL primary in one region can stream to a cross-region read replica, and that replica can be promoted to become the new primary after the disaster. Because cross-region replicas can be configured for high availability in advance, the promoted instance does not need additional changes to regain zone resilience, and cascading replicas can provide immediate protection after promotion.
A multi-regional deployment strategy distributes resources within and across regions, so service continues from surviving regions when an entire region fails. Spanner (opens in a new tab) multi-region instances, dual-region and multi-region Cloud Storage buckets, multi-cluster Bigtable instances, and Firestore multi-region locations are examples of multi-regional resources with a platform availability target of 99.999%. RTO is near zero when replication is synchronous, and a globally distributed stack provides the highest robustness against region outages. The tradeoff is between latency, consistency, and cost, with synchronous replication protecting RPO at the cost of higher write latency and asynchronous replication lowering latency at the cost of risking data loss.
Multi-regional behavior depends on the product, so the capability must be checked rather than assumed. Firestore in a multi-region location runs in a multi-zone and multi-region replicated configuration that can withstand loss of entire regions without data loss, while Firestore in a regional location runs only in a multi-zone configuration. Bigtable production instances maintain at least two clusters in unique zones with Google-managed replication, so traffic can fail over to another cluster in the same instance. Spanner regional configurations maintain three read-write replicas in different zones, each holding a full copy that can serve reads and writes, while Spanner multi-region configurations add two read-write regions plus a witness region holding a witness replica.
Exam tip: Regional protects against zone outages but not region outages, and BigQuery multi-region does not provide cross-region replication or regional redundancy because data is stored in a single region within the location.
Comparison of deployment strategies shows how wider geographic scope raises availability while lowering recovery time for larger outages. The following table summarizes platform targets and robustness when replication is synchronous, which is the condition for near-zero RTO.
| Strategy | Availability target | Zone outage robustness | Region outage robustness |
|---|---|---|---|
| Zonal | 99.9% | RTO of hours or days, manual restore or failover to another zone | RTO of hours or days, restore in another region from backup |
| Regional | 99.99% | Near-zero RTO if replication is synchronous, automatic failover to standby zone | RTO of hours or days, activate passive replica in another region |
| Multi-regional | 99.999% | Near-zero RTO if replication is synchronous, serve from surviving zones | Near-zero RTO if replication is synchronous, serve from surviving regions |
Cost and complexity rise with distribution because more resources are provisioned, more data is stored and replicated, and more cross-location traffic flows between sources and destinations. Zonal is low cost and simpler to operate, regional is medium cost and more complex than zonal, and multi-regional is high cost and more complex than regional due to redundant storage and cross-region transfer. Choose zonal when downtime of hours or days is acceptable and low latency within one zone matters, choose regional when zone failures must be absorbed automatically but region recovery by replica activation is acceptable, and choose multi-regional when both zone and region failures must be absorbed with near-zero RTO and minimal RPO.
Compare Performance, Latency, and Data Consistency is the analysis of how replica placement and replication mode affect database speed and correctness. A zonal deployment keeps data and compute in one zone for the fastest writes, a regional deployment synchronously replicates across zones in one region for zero data loss with small added latency, and a multi-regional deployment spreads copies across regions for the highest availability but must trade write latency for strong consistency. Physical distance controls this tradeoff because every synchronous confirmation must travel from the primary to each replica and back.
How distance and placement shape latency explains why the same database feels faster or slower depending on where its copies and application servers sit. Zonal resources operate within a single zone, so writes complete without cross-zone network waits. Regional resources are redundantly deployed across multiple zones in a region, so a cross-zone round trip is added to each write. Multi-regional resources are redundant within and across regions, so confirming writes across continents adds much larger delays and forces a tradeoff between latency and the consistency model.
Geographical placement of databases and application servers therefore determines observed performance. Read-only load balancing that forwards requests to the closest database gives the fastest response, especially when regional application servers sit far from the primary. High-latency links between application servers and the database must be tested for both functionality and throughput, and extra monitoring is needed to ensure cross-region replication lag does not grow with transaction load or limited network capacity.
Synchronous replication is a write pattern in which the primary database waits for confirmation from a replica before reporting a transaction as committed. Regional Persistent Disk (opens in a new tab) and Hyperdisk Balanced High Availability use this pattern to synchronously replicate disk data between two zones in the same region and protect disk data through one zonal failure. AlloyDB Omni (opens in a new tab) uses synchronous streaming replication from the primary to in-region replicas for high availability, and Cloud SQL high availability writes database files to a Regional Persistent Disk that is synchronously replicated to primary and standby zones.
Synchronous replication provides strong consistency with zero data loss for committed data, or RPO=0, during normal operation and typical failovers. The cost is write latency, because the primary cannot finish a commit until the replica confirms receipt. Application-level synchronous replication shows an explicit tradeoff on application performance, while regional disks show no effect for most applications because the cross-zone distance inside a region is short. Using synchronous replication across regions would reduce RPO for regional recovery, but it adds large transaction latency, so remote-region disaster recovery should use only asynchronous replication.
Asynchronous replication is a write pattern in which the primary commits transactions before replicas confirm them, so writes stay fast but recent changes may not yet exist elsewhere. AlloyDB Omni configures replication to a geographically separated remote replica in asynchronous mode so cross-region latency does not impact primary write performance. Cloud SQL cross-region read replicas use asynchronous replication, and Bigtable replication across clusters in multiple zones or regions is asynchronous and eventually consistent.
Asynchronous replication creates replication lag, which is the time difference between commit on the primary and commit on the replica. Transactions not yet sent from the primary become unavailable during a regional outage, producing a non-zero RPO, and transactions received but not yet processed lengthen recovery time. Because the primary does not wait for remote confirmation, RTO can be faster and write throughput stays high. In the full configuration only the primary instance performs read-write operations while replicas serve read queries, which lets read-only workloads be offloaded to nearby replicas.
Exam tip: Choose synchronous replication when the workload requires RPO=0 and can accept higher write latency; choose asynchronous replication for cross-region disaster recovery when primary write speed matters and some replication lag is acceptable.
Comparing deployment scopes by speed and consistency shows how replication distance controls latency and what guarantee survives a failure. The table below links each scope to its normal replication pattern and data-loss behavior.
| Deployment scope | Replication pattern | Latency effect | Consistency and data loss |
|---|---|---|---|
| Zonal deployment | Zonal disk snapshots with no cross-zone confirmation | No effect on application performance | Data loss depends on when the snapshot was taken |
| Regional deployment | Synchronous replication between two zones in one region | No effect for most applications; synchronous application replication adds a performance tradeoff | No data loss for committed data, or RPO=0 |
| Multi-regional deployment | Asynchronous replication across regions for disaster recovery | No wait on the primary, so primary writes stay fast | Data loss possible from replication lag; Bigtable is eventually consistent |
Product behavior follows the same pattern of protecting incoming requests first and requiring enough capacity for replication. Bigtable nodes serve both incoming requests and replication from other clusters, and Bigtable always prioritizes serving incoming requests ahead of replication traffic, so clusters must stay adequately provisioned with CPU usage and data sizes within recommended maximums. Cloud SQL recommends establishing a safe transactions per second limit that does not accumulate lag, and avoiding small configurations under 2 vCPU cores, under 100GB disks, or PD-HDD that are susceptible to lag. Cloud Storage (opens in a new tab) regional buckets store data redundantly across zones from the initial write with no lost writes on zonal loss, while dual-region and multi-region buckets store data redundantly across regions and support active-active reads and writes while remaining strongly consistent.
Assess Cost Efficiency and Compliance Constraints is the weighing of redundant copies and cross-region networks against legal limits on where data can live. A zonal deployment uses the fewest resources but fails with its zone, a regional deployment adds synchronous copies across zones in one region, and a multi-regional deployment adds copies and replicas across regions for survival of a regional outage. The wider the deployment boundary, the higher the resource, bandwidth, and management cost and the more regions that hold the data.
Cost of redundant resources across deployment scopes grows as the deployment boundary widens from zonal to regional to multi-regional. A multi-zone architecture typically has more cloud resources than a single-zone deployment, and that availability advantage against zone outages must justify the higher cost. Filestore shows the same pattern: Basic and Zonal tiers are zonal resources that are not tolerant to failure of the deployed zone or region, while the Regional tier keeps serving data from other zones after a zone failure but requires replication and extra capacity.
Firestore makes the regional versus multi-regional cost tradeoff explicit. Regional Firestore instances synchronously replicate data across at least three zones, and a regional location offers lower costs, lower write latency, and co-location with other Google Cloud resources. Firestore multi-regional instances synchronously replicate data across five zones in three regions, with two serving regions and one witness region, so committed data survives zonal and regional failure but requires storage and synchronous writes in far more locations. AlloyDB Omni (opens in a new tab) Premium Availability follows the same logic with three read-replica standbys in three availability zones and two regions, where synchronous streaming replication to local replicas provides high availability and asynchronous streaming replication to a geographically separated replica provides disaster recovery.
| Deployment | Where data is stored | Cost and resilience tradeoff |
|---|---|---|
| Zonal | Single zone, such as Filestore Basic and Zonal tiers | Fewest resources, but not tolerant to zone or region failure |
| Regional | Synchronously across zones in one region, such as Firestore across at least three zones and Filestore after persistence in two zones | More resources than single-zone, with lower cost and lower write latency than multi-regional and survival of zonal failure |
| Multi-regional | Across zones and regions, such as Firestore across five zones in three regions and AlloyDB Omni across three zones and two regions | Most resources plus cross-region bandwidth and monitoring, but survives zonal and regional failure |
Network and operational overhead for wider boundaries is the extra bandwidth, latency management, and monitoring required when replicas span zones and regions. AlloyDB Omni evaluations must consider network latency and bandwidth within the region and across regions, geographical placement of databases and application servers, strategy for offloading read-only workloads to replicas, and high availability in the remote disaster recovery region. Read-only load balancing may be required so requests from regional application servers are forwarded to the closest database for the fastest response, and extra monitoring is required for cross-region replication to ensure that replication lag does not grow because of transaction load or network capacity.
The replication mode controls how that overhead affects the primary database. In AlloyDB Omni, data flows from the primary instance to in-region replicas in synchronous mode and to cross-region replicas in asynchronous mode to avoid letting cross-region latency slow primary write performance. Only the primary instance can perform read-write operations while the other replicas serve read queries, so the application depends on the primary for writes and on load balancing for reads. Thorough disaster recovery testing is required to verify application functionality and throughput when high-latency network connections sit between application servers and the database.
Availability planning should account for the following related factors:
These factors explain why a multi-regional design costs more than storage alone, because bandwidth, load balancers, standby capacity, and testing all grow with distance and replica count.
Data residency and deployment boundaries define which regions are allowed to store and serve a copy of the data under regulatory and operational rules. Customers choose the Google Cloud region for services such as Document AI and Eventarc, and that choice acts as a hard boundary. Document AI stores user documents and processor version data regionally with synchronous writes, so traffic automatically routes to other zones after a zonal failure but data is never replicated across regions and Document AI will not fail over during a regional outage. Eventarc stores trigger metadata regionally and returns an API call only after the data has been committed to a quorum within a region, so data plane operations survive zonal failure and requests flow from unavailable zones to available zones, but customer traffic is never routed by Eventarc to a different region.
The same boundary choice appears in database services with different defaults. A regional Firestore instance keeps synchronous copies inside one region, while a multi-regional instance intentionally places data in three regions to survive regional failure. Filestore Regional tier continues to serve reads and accept new writes from surviving zones after a zone failure, with possible degraded performance, and clients are advised to create external backups that can restore the instance to other regions if more zones in the same region fail. AlloyDB Omni crosses a large geographic boundary by design when asynchronous streaming carries data from the primary region to the remote disaster recovery region, so placement of the primary, the local synchronous replicas, and the remote asynchronous replica determines which jurisdictions hold the data.
Exam tip: Regional storage survives zonal failure without leaving the chosen region and does not fail over to another region, while multi-regional storage survives regional failure because copies already exist in other regions.
Last updated