---
title: "Real-life scenario: Global Service Platform"
chapter: "16"
---

# Real-life scenario: Global Service Platform

This fictional scenario shows how a GKE architect supports a global enterprise.

## Situation

ToolWorks sells equipment in 55 countries. Customer web/mobile channels use
APIs running on GKE. SAP owns orders and product prices, Salesforce owns sales
activity, and Workday owns employee/territory data. Campaign traffic grows ten
times. Teams currently deploy manually and one bad cluster role can affect all
applications.

Goals: faster delivery, 99.95% checkout availability, controlled personal data,
no duplicate orders, recovery within one hour with no more than five minutes of
data loss, and clear platform cost.

## Architecture decision

Use separate production and non-production projects in a governed folder,
Shared VPC, central logging/security projects, and regional Autopilot clusters.
Autopilot reduces node operations; no workload has a proven node-level need.
Fleets group clusters, while Config Sync and Policy Controller roll out platform
configuration through audit, canary, and enforcement stages.

Cloud Load Balancing and Gateway API expose services; Cloud Armor protects the
public edge. Private nodes, Cloud NAT, Private Google Access, Dataplane V2, and
default-deny NetworkPolicy control paths. Each workload has a dedicated
Kubernetes service account mapped through Workload Identity Federation.

Artifact Registry holds scanned immutable images. CI builds once and produces
provenance. Binary Authorization permits approved images. Cloud Deploy canaries
releases and stops promotion when SLO burn is high.

## Enterprise integration

Customer APIs commit channel transactions to a managed database and publish
orders to Pub/Sub. A GKE worker consumes idempotently and calls the governed SAP
integration API. Pub/Sub buffers campaign spikes and failed messages enter a
dead-letter path with reconciliation. Salesforce and Workday changes arrive
through approved APIs/files into normalized events. No service reads another
system's database directly.

## Reliability

Deployments use at least three replicas, topology spread, readiness/startup
probes, graceful termination, and disruption budgets. HPA scales from request
and queue signals. Autopilot provides capacity; load tests include cold scale-up.
Cloud SQL/Spanner design follows data requirements and the agreed RPO.

Backup for GKE protects Kubernetes resources and eligible volumes; IaC rebuilds
clusters and cloud services; registries preserve images. A prepared secondary
region receives restored configuration/data during scheduled game days. DNS and
traffic failover are tested, not assumed.

## Operations and outcomes

Cloud Monitoring dashboards show checkout SLO, latency, Pub/Sub backlog, SAP
errors, Pod restarts, unschedulable Pods, rollout status, security findings, and
cost per order. Measure duplicate orders, recovery time, deployment frequency,
change failure rate, policy violations, and idle requested CPU.

## Important trade-offs

- Autopilot removes node management but limits privileged/node-level patterns.
- Async SAP integration protects checkout but introduces a pending order state.
- A fleet creates consistency but a bad global policy creates wide blast radius.
- Multi-region recovery meets the business target but requires rehearsed data,
  identity, secrets, DNS, and operations—not only a second cluster.