A large e-commerce company is migrating its monolithic application to GCP. The application requires high-availability and regional fault tolerance…

This architecture provides a comprehensive solution for a highly available, multi-region application. The Global External HTTP(S) Load Balancer uses a single global IP address to route users to the closest healthy Regional Managed Instance Group, minimizing latency and providing seamless failover if one region becomes unavailable. The use of Regional Managed Instance Groups ensures the stateless front-end is resilient to zonal failures within each region. For the database, Cloud Spanner is the ideal choice as it is a globally distributed, strongly consistent database designed for multi-region fault tolerance and high availability (99.999% SLA). Its PostgreSQL interface facilitates the migration from the existing PostgreSQL backend while meeting the stringent availability requirements.

A. Cloud Storage is an object store, not a relational database system. It cannot replace the functionality of a PostgreSQL backend for a transactional e-commerce application.

B. This option describes a single-region architecture. A regional GKE cluster, Regional Persistent Disk, and Cloud SQL are all confined to one region and do not provide regional fault tolerance.

D. Cloud SQL for PostgreSQL is a regional service. While it supports cross-region read replicas, failover is a manual process and does not provide the seamless, active multi-region capability required. Cloud Spanner is purpose-built for this scenario.

1. Global Load Balancing and MIGs: Google Cloud Documentation, "External HTTP(S) Load Balancing overview," describes how the global load balancer can direct traffic to backends (like Managed Instance Groups) in the region closest to the user. It also details the automatic failover capabilities. (See section: "How External HTTP(S) Load Balancing works").

2. Cloud Spanner for Multi-Region Databases: Google Cloud Documentation, "Spanner instances," explains that multi-region instances "replicate data in multiple regions... and can tolerate the loss of an entire region." The documentation on the "PostgreSQL interface" confirms its suitability for migrating from PostgreSQL.

3. Cloud SQL Regional Nature: Google Cloud Documentation, "Cloud SQL high availability configuration," states, "The HA configuration provides high availability for a Cloud SQL instance within a single region." This highlights its limitation for multi-region fault tolerance compared to Cloud Spanner.

4. Architectural Best Practices: Google Cloud Architecture Framework, "Reliability pillar," emphasizes designing for resilience across zones and regions. The document states, "For global applications with the highest availability requirements (for example, 99.999%), we recommend a multi-region architecture... For relational database workloads, we recommend that you use Cloud Spanner." (See section: "Disaster recovery patterns").