Google Cloud PCA architecture decisions: choose compute, databases, and HA from requirements

October 25, 2026 · 14 min read

Practice Professional Cloud Architect decisions through an original order API case. Compare Cloud Run and GKE, Cloud SQL and Spanner, HA and disaster recovery, and cost controls, explaining the choice, rejected alternatives, and validation before adoption.

Practice PCA architecture decisions through an order API case

Preparing for Google Cloud Professional Cloud Architect (PCA) can leave a gap between knowing service features and choosing an architecture. Practice turning requirements into evidence for a decision. This original order API case connects compute, operational databases, recovery, and cost, then asks what changes would warrant a different choice.

Separate mandatory constraints from comparison criteria

A hypothetical six-person team is moving an order API with an existing MySQL database to Google Cloud. Its HTTP containers keep no persistent local data and require neither Kubernetes-specific features nor guest OS modifications. The business wants reliable campaign ordering with less infrastructure maintenance.

Requirement	Case assumption	Decision implication
Load and response	Peak 200 req/s; at least 95% of eligible order requests respond within 500 ms during normal operation	Include startup and DB waits in measurement; set incident targets separately
Compatibility and writes	Preserve existing MySQL SQL and transactions; single-writer capacity is unverified	Check supported features and representative write load first
Failure scope	Prepare for zone failure; target regional recovery within 30 minutes and a data-loss window within 5 minutes	Need both HA and DR; evaluate RTO and RPO separately
Location and access	Agree permitted locations for authoritative data, replicas, and backups; restrict business-data access	Choose an eligible DR location; verify connectivity, authentication, and authorization
Team and cost	Small on-call team; proposed monthly budget, but no agreed ceiling or priority	Include operational effort; budget alerts alone cannot meet a spending ceiling

Specify the client-side boundaries of the 500 ms measurement, how failed requests count, and the reporting window. A lower price or a high score elsewhere cannot compensate for failing a mandatory constraint. If cost and quality cannot both fit, revisit capability or targets with the business.

Decision order for this case; adoption depends on validation

Business goals and constraints → Compute and database candidates → HA, DR, and operating plan → Decide using cost and validation

Compare Cloud Run, GKE, and Compute Engine by required control

Cloud Run is the first candidate for this HTTP API because reducing infrastructure management supports the team's goal. Starting a container is only the beginning of validation. Check the runtime contract for ports, request deadlines, shutdown, and the location of persistent state.

Candidate	Reason to prioritize evaluation	Work the team retains
Cloud Run	HTTP services or jobs that fit its runtime and need less infrastructure management	Application, permissions, connections, observability, load settings
GKE	Required Kubernetes APIs, placement, or policy capabilities	Application and Kubernetes resources; Autopilot retains responsibilities
Compute Engine	Required guest OS or kernel control	OS updates, capacity, redundancy, and recovery

A container alone does not justify GKE, and an existing VM alone does not justify retaining guest OS management. Required Kubernetes controls or an established Kubernetes operating platform could change the comparison. Include team experience and assess separate workloads on their own requirements.

Choose Cloud SQL or Spanner by compatibility and writes

Cloud SQL for MySQL is the candidate for preserving this application's existing engine. Check its version, SQL, features, and connectivity, then measure peak writes and contention. Spanner offers distributed strong consistency and horizontal read/write scaling, but anticipated growth alone does not justify the migration changes.

Dimension	Validate with Cloud SQL	Validate with Spanner
Compatibility	Existing engine features, SQL, and drivers	SQL, types, drivers, and transaction changes
Writes	Required update rate, lock contention, single-writer headroom	Key skew, distributed contention, and scaling
Placement and latency	User-to-database distance and replica roles	Latency and cost for the configuration and write location
Adoption cost	Resizing, HA, migration, and recovery operations	Application and schema changes, migration, and recovery operations

Cloud SQL read replicas offload reads; they do not distribute primary writes across more writers. Spanner's PostgreSQL interface also does not implement every PostgreSQL feature. These two candidates narrow the operational transaction database comparison for this case; they do not exhaust all database options.

Validate autoscaling together with database capacity

More API instances can create more database connections. A connection pool reuses connections after work completes. Adding application instances does not necessarily increase database write throughput; connection waits or lock contention may deteriorate first.

Illustrative connection arithmetic, not product defaults or recommended settings

Assumed concurrent instances = 20
Total pool limit per instance = 8
Other connections, including batches and administration = 40

Expected connections = 20 × 8 + 40 = 200
Operational connection budget established by testing = 240
Remaining difference under these assumptions = 240 - 200 = 40

The 240 is a hypothetical operating budget, not a Cloud SQL product limit; 20 is an assumed running instance count. Sum per-process pools and account for other services, deployment connections, and reconnection surges. Cloud Run's maximum instances setting can be temporarily exceeded, so instance settings alone do not enforce a strict database connection ceiling.

Under a representative 200 req/s load, measure latency, success rate, actual instances, database connections, and waits. Include the slow end of the distribution, not only averages.
Exercise startup, deployments, and database reconnection. Vary request concurrency and connection pools to find saturation conditions.
Bound connection acquisition waits and request duration. Define rejection and retry behavior when capacity runs out rather than forwarding unbounded work downstream.

Separate HA from DR and measure RTO and RPO through business recovery

Cloud SQL for MySQL regional HA places a primary and standby in different zones of one region. It addresses zone or instance failure; a regional outage needs another recovery path. Existing connections close during failover, so test application reconnection and order outcome checks too.

Failure	Candidate mechanism	Validate
Zone or instance failure	HA within one region	Reconnection, in-flight orders, recovered capacity
Entire region unavailable	Replica and application recovery path in another region	Permitted location, promotion, cutover, RTO and RPO
Accidental deletion or updates	Backups or point-in-time recovery	Restore the required history, reconcile orders, measure resumption

RTO, recovery time objective, specifies the allowed time from failure to business resumption. RPO, recovery point objective, specifies the acceptable data-loss window. Cross-region read replication is asynchronous, so promotion can lose unapplied orders. Having a replica alone establishes neither zero RPO nor a five-minute bound.

Assumed serial durations for an original DR rehearsal total 23 minutes; these are not product recovery guarantees

Detection and decision: 4 min
DB promotion and checks: 6 min
Application and endpoint cutover: 8 min
Order checks and resumption: 5 min

If the rehearsal takes 4 + 6 + 8 + 5 = 23 minutes, the remaining margin against 30 minutes is seven minutes. The six-minute database promotion is only part of RTO. Repeat with unavailable operators and failed control operations. Assess RPO separately by reconciling recovered orders against an independent record of committed orders kept for the rehearsal. Short replication lag during normal operation does not establish a maximum loss during disaster.

Assign the cutover decision and its trigger; prepare the other region's database, application, permissions, and connectivity.
Establish one authoritative writer and prevent competing writes from the original region. Check promotion procedures for the selected engine and edition.
Switch application endpoints and routing, then exercise representative order writes and reads. Reconcile orders with unknown outcomes by order ID or another suitable identifier before retrying.
Define handling for lost orders, redundancy in the new topology, and return to the original region. Rehearse accidental-deletion recovery separately.

Decide rightsizing, usage controls, and CUDs separately

Removing HA to save money would conflict with this case's mandatory constraints. Estimate API execution, HA databases, cross-region replicas, backups, transfer, logs, and operational effort over the same scope. Remove idle resources and oversized settings first, checking that required quality remains achievable.

Mechanism	Purpose	Case decision
Alerts-only budget	Notify on spending trends and thresholds	Assign recipients and responders; do not treat it as an automatic ceiling
Usage controls	Restrict work or resource consumption	Agree production impact; check supported services and scope for spend cap budgets
Committed use discount (CUD)	Discount in exchange for committed usage or spending	Evaluate the rightsized stable baseline; obligations can remain when demand disappears

Scheduling test environments has a different impact from reducing production headroom. Evaluate CUD eligibility and observed stable demand instead of immediately committing to the peak. A discount commitment is not a spending ceiling, and budget notifications do not design availability-preserving usage controls for the order system.

Practice: what changes when one condition changes?

These three questions are original exercises. Answer in the order constraint, candidate, rejected alternatives, and validation before reading the explanations. Add one check that would establish adoption readiness instead of stopping at a product name.

Change or question	Options
1. The HTTP API requirements stay the same and the team wants less infrastructure maintenance. Which candidate comes first?	A: Cloud Run; B: GKE Standard; C: VMs managed from the guest OS up
2. MySQL compatibility is no longer needed, and measurements establish a need for horizontal write scaling with strong consistency. What comes first?	A: More Cloud SQL read replicas; B: Spanner placement, keys, and latency; C: More API instances only
3. Database promotion took six minutes. Does that establish the 30-minute RTO?	A: Yes; B: Yes if regional HA exists; C: Measure from failure through detection and business resumption

1: A. Cloud Run is a candidate if its runtime fits. This case has no Kubernetes or OS-control requirement to justify their additional operating work. Measure the response target including startup and database connections.
2: B. Read replicas or API instances alone do not meet distributed write requirements. Validate Spanner key skew, required transactions, latency, and cost before adoption.
3: C. Promotion is one recovery step. Include detection, decisions, application and endpoint cutover, and order checks. RPO needs separate validation.

Record the choice with validation and review triggers

The provisional design is Cloud Run with regional HA Cloud SQL for MySQL. Evaluate a replica in another permitted region and an application recovery path for regional failure. Adoption depends on SQL compatibility, quality at 200 req/s, connection capacity, a 30-minute RTO and five-minute RPO, and agreed cost.

Illustrative decision record; unperformed tests remain unverified

Status: provisional; load, failure, and recovery tests not yet performed
Goal: meet ordering quality with less infrastructure maintenance for a small team
Candidate: Cloud Run + Cloud SQL for MySQL (regional HA)
DR: validate a replica and application recovery path in another permitted region
Alternatives: no current need for GKE/VM control; Spanner migration cost not yet justified
Open checks: SQL, connections, latency, RTO/RPO, reconciliation, permissions, cost
Review triggers: write capacity exhausted, Kubernetes required, zero-loss requirement, location change

Finally, use the Well-Architected Framework's operations, security, reliability, performance, cost, and sustainability perspectives to find gaps. This case still needs concrete authentication, authorization, location, monitoring, on-call, and migration-cutover designs before adoption. The learning goal is to explain who validates what and when the decision must be revisited, including the responsibilities retained with managed services.