An enterprise is designing a highly resilient database architecture on Google Cloud for a mission-critical transactional service. The workload has the following architectural and reliability requirements: Local High Availability (HA): Requires an RPO of zero (no data loss) and an RTO of less than 60 seconds with automated failover in the event of a primary database instance or zone failure. Performance: Transactional write latency must not be severely degraded by long-distance network round-trips during standard operations. Disaster Recovery (DR): Protection against total regional failure by maintaining a standby disaster recovery site in a geographically distant secondary region. Cluster Management: Automated health detection, distributed consensus, and leader election. Following the Google Cloud Well-Architected Framework for reliability, which database architecture should you implement?

Implement synchronous streaming replication between the primary and standby replicas managed by Patroni and a distributed consensus store (such as etcd) within the primary region, and configure asynchronous streaming replication to the secondary disaster recovery region.: What This Architecture Is This architecture combines intra-region high availability (HA) using synchronous streaming replication with inter-region disaster recovery (DR) using asynchronous streaming replication. High availability is automated and coordinated using Patroni alongside a distributed consensus system such as etcd, Consul, or ZooKeeper. How It Meets the Requirements Zero RPO locally: Synchronous streaming replication ensures that all committed transactions are written to standby replicas before acknowledging the client, delivering an RPO of 0 for local/zonal failures. Sub-minute RTO: Patroni continuously monitors database health and coordinates automated leader election, switching traffic to a healthy standby in under 60 seconds without manual intervention. Low transactional latency: Keeping synchronous replication within low-latency boundaries (intra-region / close proximity) prevents write latency degradation. Regional Disaster Recovery: Asynchronous replication transmits changes to a secondary region hundreds or thousands of kilometers away without stalling primary transactions on long-distance network round-trips. Key Advantages and Capabilities Automated failover: Eliminates human latency during zonal outages using distributed consensus. Optimized latency boundaries: Separates zero-loss synchronous replication (low latency) from cross-region asynchronous replication (high latency). Immediate post-failover protection: Secondary regions can host multiple standby instances to restore resilience immediately after a regional cutover. Continuous health checks: Automated node heartbeat monitoring and health checks prevent split-brain scenarios. Why This Is Optimal Synchronous replication across distant geographic regions introduces substantial network round-trip latency that severely slows down transactional writes. By confining synchronous replication to local low-latency nodes and using asynchronous replication for cross-region disaster recovery, this solution balances stringent RPO/RTO requirements with optimal application performance.

StudyCerts

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Database Ha Dr Replication Strategy Patroni

Section: Familiarity with the Google Cloud Well-Architected Framework

An enterprise is designing a highly resilient database architecture on Google Cloud for a mission-critical transactional service. The workload has the following architectural and reliability requirements:

Local High Availability (HA): Requires an RPO of zero (no data loss) and an RTO of less than 60 seconds with automated failover in the event of a primary database instance or zone failure.
Performance: Transactional write latency must not be severely degraded by long-distance network round-trips during standard operations.
Disaster Recovery (DR): Protection against total regional failure by maintaining a standby disaster recovery site in a geographically distant secondary region.
Cluster Management: Automated health detection, distributed consensus, and leader election.

Following the Google Cloud Well-Architected Framework for reliability, which database architecture should you implement?

...

Implement asynchronous replication locally between the primary and standby replicas using periodic pgBackRest WAL archiving, and configure synchronous streaming replication across geographically distant regions.

...

Implement synchronous streaming replication between the primary and standby replicas managed by Patroni and a distributed consensus store (such as etcd) within the primary region, and configure asynchronous streaming replication to the secondary disaster recovery region.

...

Implement synchronous multi-region streaming replication across multiple geographical regions and configure manual failover runbooks triggered by Cloud Monitoring alert notifications.

...

Deploy a single standalone active database instance in each region, relying on scheduled daily snapshot backups and point-in-time WAL replay for cross-region recovery.

...

Explanations

What This Architecture Is

This architecture combines intra-region high availability (HA) using synchronous streaming replication with inter-region disaster recovery (DR) using asynchronous streaming replication. High availability is automated and coordinated using Patroni alongside a distributed consensus system such as etcd, Consul, or ZooKeeper.

How It Meets the Requirements

Zero RPO locally: Synchronous streaming replication ensures that all committed transactions are written to standby replicas before acknowledging the client, delivering an RPO of 0 for local/zonal failures.
Sub-minute RTO: Patroni continuously monitors database health and coordinates automated leader election, switching traffic to a healthy standby in under 60 seconds without manual intervention.
Low transactional latency: Keeping synchronous replication within low-latency boundaries (intra-region / close proximity) prevents write latency degradation.
Regional Disaster Recovery: Asynchronous replication transmits changes to a secondary region hundreds or thousands of kilometers away without stalling primary transactions on long-distance network round-trips.

Key Advantages and Capabilities

Automated failover: Eliminates human latency during zonal outages using distributed consensus.
Optimized latency boundaries: Separates zero-loss synchronous replication (low latency) from cross-region asynchronous replication (high latency).
Immediate post-failover protection: Secondary regions can host multiple standby instances to restore resilience immediately after a regional cutover.
Continuous health checks: Automated node heartbeat monitoring and health checks prevent split-brain scenarios.

Why This Is Optimal

Synchronous replication across distant geographic regions introduces substantial network round-trip latency that severely slows down transactional writes. By confining synchronous replication to local low-latency nodes and using asynchronous replication for cross-region disaster recovery, this solution balances stringent RPO/RTO requirements with optimal application performance.

View source documentation

Professional Cloud Architect

Database Ha Dr Replication Strategy Patroni

Professional Cloud Architect

Database Ha Dr Replication Strategy Patroni

What This Architecture Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Related questions

Ask Scout