Technical blueprint, not a client delivery

Designing Cloud Run scale around database limits

A serverless API can absorb demand faster than its database, making connection capacity a failure point as traffic grows.

This blueprint sets explicit compute and connection limits alongside protected ingress, private data access, and a controlled release path across two regions.

The design would bound service scaling to database capacity and make regional recovery steps explicit.

A serverless service can still overload its dependencies. Direct service URLs can bypass a front door, cold starts affect latency, and every new instance can open more database connections. Regional compute does not by itself make a database multi-writer or provide disaster recovery.

A Cloud Run blueprint that coordinates instance scaling with database connection limits, restricts ingress, and separates multi-region compute from the single write-primary data design.

Global request, bounded data path

Traffic is distributed across regional compute, but state still follows a declared primary/replica topology.

A regional failover and a database promotion are distinct operations and require separate validation.

Request: Global HTTPS entry: The load balancer receives the public request and applies Cloud Armor policy. → Regional Cloud Run: A serverless NEG routes to a service revision in an available region. → Private dependency: VPC egress reaches private Cloud SQL and Memorystore endpoints.
Release: Build once: Cloud Build creates a versioned image for Artifact Registry. → Progressive delivery: Cloud Deploy shifts traffic between revisions and can promote or roll back the release.
Global entry: One global HTTPS load balancer and Cloud Armor policy direct requests; Cloud CDN and Cloud Storage serve static assets. Global external Application Load Balancer, Cloud Armor, Cloud CDN, Cloud Storage
Regional services: Cloud Run services in two regions scale by configured concurrency and instance limits. Cloud Run, Concurrency, Minimum instances, Maximum instances
Private data path: Cloud Run is managed outside the VPC; its Direct VPC egress uses regional subnets to reach private cache and a single write-primary database with a cross-region read replica. The regional diagram groups show connectivity, not Cloud Run ingress into a subnet. Direct VPC egress, Cloud SQL, Memorystore, Connection pools
Controlled release: Cloud Build creates an artifact and Cloud Deploy progressively shifts traffic between Cloud Run revisions. Cloud Build, Artifact Registry, Cloud Deploy, Canary revisions
Operations and identity: Per-service identities, secret storage, telemetry and infrastructure-as-code support day-two operation. IAM service accounts, Secret Manager, Cloud Monitoring, Cloud Logging, Terraform
How can stateless scaling avoid overwhelming Cloud SQL? Instance count multiplied by each pool, across services, regions and overlapping revisions, can exceed database connection capacity. Set per-service maximum instances and connection pools against a shared connection budget with headroom. Compute has an explicit ceiling tied to the stateful dependency instead of scaling independently.
Does two-region compute mean active-active data? A regional Cloud SQL replica is not an independent write primary. Keep one write primary and a cross-region read replica; define a deliberate promotion procedure for regional loss. The serving topology and recovery posture are explicit, but cross-region write latency and recovery time remain workload-specific.
Can a request bypass edge policy? A public service URL can create another entry path around the global load balancer. Configure Cloud Run ingress for the intended load-balancer path and verify direct URL access is refused. The advertised edge controls remain in the request path.

The operational failure modes this design addresses.

Warm minimum instances reduce some cold-start exposure but cost money while idle. Two-region compute can improve serving resilience, but a single write primary leaves cross-region write latency and a database recovery procedure. Connection limits protect Cloud SQL, while lowering maximum instances can constrain burst capacity.

Connection budget: Scale compute within the database envelope. Maximum instances, per-instance connection pools, services, regions and overlapping revisions all contribute to the possible connection count. Pooling and headroom must be sized against Cloud SQL limits.
Ingress integrity: Keep the supported front door in the request path. Restrict Cloud Run ingress so clients cannot bypass the global load balancer and its Cloud Armor policy through a direct service URL.
Regional resilience: Separate serving capacity from write topology. Two regions can serve requests while Cloud SQL remains a single write primary with a cross-region read replica. Promotion is an operational recovery action, not automatic multi-writer behavior.
Global HTTPS load balancing, Cloud Armor and Cloud CDN sit in front of regional Cloud Run services.
Concurrency, minimum and maximum instances, connection pooling and regional revision overlap are considered together.
Cloud Run reaches private Cloud SQL and Memorystore through VPC egress; the design does not claim multi-writer SQL.
Cloud Build and Cloud Deploy promote Cloud Run revisions as a canary, with traffic movement as the rollback mechanism.

How the system is intended to work.

A Cloud Run blueprint that coordinates instance scaling with database connection limits, restricts ingress, and separates multi-region compute from the single write-primary data design.

Protected request path: Global HTTPS load balancing, Cloud Armor and Cloud CDN sit in front of regional Cloud Run services.
Database-aware scaling: Concurrency, minimum and maximum instances, connection pooling and regional revision overlap are considered together.
Private dependencies: Cloud Run reaches private Cloud SQL and Memorystore through VPC egress; the design does not claim multi-writer SQL.
Progressive delivery: Cloud Build and Cloud Deploy promote Cloud Run revisions as a canary, with traffic movement as the rollback mechanism.
Global entry: One global HTTPS load balancer and Cloud Armor policy direct requests; Cloud CDN and Cloud Storage serve static assets. Global external Application Load Balancer Cloud Armor Cloud CDN Cloud Storage
Regional services: Cloud Run services in two regions scale by configured concurrency and instance limits. Cloud Run Concurrency Minimum instances Maximum instances
Private data path: Cloud Run is managed outside the VPC; its Direct VPC egress uses regional subnets to reach private cache and a single write-primary database with a cross-region read replica. The regional diagram groups show connectivity, not Cloud Run ingress into a subnet. Direct VPC egress Cloud SQL Memorystore Connection pools
Controlled release: Cloud Build creates an artifact and Cloud Deploy progressively shifts traffic between Cloud Run revisions. Cloud Build Artifact Registry Cloud Deploy Canary revisions
Operations and identity: Per-service identities, secret storage, telemetry and infrastructure-as-code support day-two operation. IAM service accounts Secret Manager Cloud Monitoring Cloud Logging Terraform

Test the boundaries before relying on the design.

The following checks define evidence to collect before implementation is accepted. None is represented as already run.

Protected request path: Global HTTPS load balancing, Cloud Armor and Cloud CDN sit in front of regional Cloud Run services.
Database-aware scaling: Concurrency, minimum and maximum instances, connection pooling and regional revision overlap are considered together.
Private dependencies: Cloud Run reaches private Cloud SQL and Memorystore through VPC egress; the design does not claim multi-writer SQL.
Progressive delivery: Cloud Build and Cloud Deploy promote Cloud Run revisions as a canary, with traffic movement as the rollback mechanism.
Ingress restriction: Call the service URL directly and verify the configured ingress policy rejects requests that bypass the load balancer.
Connection ceiling: Load test at maximum configured instances and verify total database connections stay within the reserved budget.
Regional failure: Fail one service region and verify traffic behavior, then separately rehearse replica promotion and write recovery.
Canary rollback: Inject a failing signal during a canary and verify traffic returns to the previous revision.
Private endpoints: Verify Cloud SQL and Memorystore have no public IP path.
No measured performance, cost, recovery or compliance outcome is published for this project.

A design that makes operational boundaries reviewable.

The intended organizational effect is a scale plan tied to database capacity and a recovery procedure that separates serving-region failure from database promotion. This remains a reference design. No measured performance, cost, recovery or compliance outcome is published for this project.

Bound demand on Cloud SQL: Instance limits and connection pools give teams a capacity budget to test before increasing traffic.
Make recovery decisions explicit: Regional traffic movement and database promotion have separate owners and validation steps.

Review the constraints before selecting the implementation.

Start with workload limits, owners and failure behavior. Then turn the validation plan into environment-specific tests and acceptance criteria.