Multi-Region Readiness

Multi-Region Readiness

This page describes the current single-region architecture, what already supports multi-region, and the path to expanding to additional regions if required.

---

1. Current State: Single Region

The CM Marketplace platform currently runs entirely in europe-west4 (Eemshaven, Netherlands). This is a deliberate choice:

• Data residency: EU data stays in EU infrastructure
• Latency: Primary customer base is in Europe
• Simplicity: Single-region reduces operational complexity
• Cost: No cross-region replication overhead

Within this region, the platform achieves zone-level redundancy (see Geographic Redundancy page for details).

---

2. Components Already Multi-Region Ready

Several components are already designed in a way that makes multi-region expansion straightforward:

Stateless Services (Cloud Run)

All 11 Cloud Run services are stateless — they read configuration from the Configuration Service and cache from Redis. Deploying them in a second region requires only:

1. A new Terraform environment directory (e.g., infra/environments/production-us/)
2. Updated image references pointing to the same Artifact Registry
3. A regional load balancer to route traffic

# Current: single environment
infra/environments/production/         # europe-west4

# Multi-region: add a second environment
infra/environments/production-us/      # us-central1 (example)

Container Images (Artifact Registry)

Images are stored in Artifact Registry which supports multi-region repositories. The same image can be pulled from any GCP region without cross-region latency.

Database Backups

Backups are already stored in the eu multi-region location:

backup_configuration {
  location = "eu"    # Accessible from any EU region
}

This means a database can be restored in any EU region (e.g., europe-west1, europe-west3) from existing backups.

Pub/Sub

Google Cloud Pub/Sub is inherently global — topics and subscriptions are not bound to a single region. Messages published in one region can be consumed by subscribers in another.

Secrets

Google Secret Manager supports automatic replication — secrets can be configured to replicate to multiple regions.

---

3. Components Requiring Changes for Multi-Region

Cloud SQL Database

Current: Single regional instance in europe-west4.

For multi-region, options include:

Option	Approach	Trade-off
Cross-region read replicas	Add read replicas in target region	Read scaling, eventual consistency
Cloud SQL cross-region failover	Cross-region HA instance	Higher cost, automatic failover
Separate databases per region	Independent databases with sync	Full independence, complex sync

Redis Cache

Current: Single BASIC instance in europe-west4-c.

For multi-region: Deploy a separate Memorystore instance per region. Since cache is ephemeral and regenerated from the database, no cross-region replication is needed.

Cloud Tasks

Current: Regional queues in europe-west4.

For multi-region: Create separate task queues per region. Task dispatching is already region-scoped.

VPC and Networking

Current: Single VPC with regional NAT.

For multi-region: Each region needs its own VPC (or shared VPC with regional subnets), NAT gateway, and VPC Access Connector. External partners may need to allowlist additional static IPs.

CI/CD Pipeline

Current: Single deploy-prod.yaml targeting europe-west4.

For multi-region: Extend the pipeline to deploy to multiple environments sequentially or in parallel:

# Conceptual multi-region deploy
jobs:
  deploy-eu:
    environment: Production-EU
    # terraform apply for europe-west4
  deploy-us:
    needs: deploy-eu
    environment: Production-US
    # terraform apply for us-central1

---

4. Architecture Suitability

The platform's modular Terraform architecture makes multi-region expansion practical:

• Each environment is a separate directory composing the same modules
• Module variables control region-specific settings (region, zones, IP ranges)
• Service configuration (adapters, tenants) lives in the database — not hardcoded

The adapter pattern is region-agnostic — adapters connect to external platforms over the internet, so they work identically regardless of which GCP region hosts the service.

What Makes This Feasible

Aspect	Why It Helps
Terraform modules	Same modules, different variables per region
Stateless services	No local state — deploy anywhere
Configuration Service	Tenant config in database, not environment
Adapter pattern	External APIs are internet-accessible from any region
Pub/Sub (global)	Cross-region event delivery built-in
EU backups	Database restorable in any EU region

What Needs Engineering Work

Aspect	Effort
Global load balancer	Moderate — GCP Global HTTP(S) LB with Cloud Run backends
Database replication	High — cross-region read replicas or active-active
DNS and routing	Low — Cloud DNS with geo-routing
Per-region Redis	Low — deploy new Memorystore instance
Per-region NAT IP	Low — new static IP, update partner allowlists
Pipeline updates	Moderate — parallel or sequential multi-region deploy

---

5. Recommended Approach

If multi-region is required, the recommended path is:

1. Phase 1: Deploy read-only services in second region with cross-region DB read replica
2. Phase 2: Add Global Load Balancer with geo-routing
3. Phase 3: Independent database per region with event-based sync (if full independence needed)

This incremental approach minimizes risk while progressively increasing geographic resilience.

Last updated: May 2026