Designing cloud-native applications

Choosing a compute platform

Rules of thumb. Start from the most managed option that satisfies the requirements: Cloud Run before GKE before Compute Engine. Choose GKE when the question mentions Kubernetes, sidecars, service mesh, a StatefulSet or existing Helm charts. Choose Compute Engine when the question says legacy, license tied to a VM, or needs to install a kernel module. The service level (IaaS, CaaS, PaaS, FaaS) shows how much you manage: Compute Engine is IaaS, GKE is CaaS, App Engine is PaaS, Cloud Run functions is FaaS, and Cloud Run sits between CaaS and PaaS.

Containers on Cloud Run and GKE

• Build and refactor: a container must listen on the port in the PORT environment variable on Cloud Run (default 8080), bind to 0.0.0.0, keep no state locally, read config from environment variables and secrets, log to stdout/stderr, and handle SIGTERM for graceful shutdown (Cloud Run gives about 10 seconds).
• Small images start faster: multi-stage builds, slim or distroless bases. No Dockerfile? Buildpacks can build from source (gcloud run deploy --source .).
• Push to Artifact Registry, then deploy by image URL (REGION-docker.pkg.dev/PROJECT/REPO/IMAGE:TAG), or better, by digest so the revision is immutable.
• Refactoring a monolith: split by business capability, give each service its own data, communicate through APIs and events, and put cross-cutting concerns (auth, rate limits, observability) in the platform rather than every service.

Cloud Run settings that get tested

If a downstream database allows 100 connections, cap max instances x concurrency below it or add a pool. If requests are CPU-heavy, lower concurrency; for I/O-bound services raise it.

Geography: regional, zonal, global

Know the scope of each service because it drives latency and failure behaviour.

• Zonal: Compute Engine VMs, persistent disks, zonal GKE clusters. A zone outage takes them down.
• Regional: Cloud Run, regional managed instance groups, regional GKE clusters (control plane and nodes across three zones), Cloud SQL HA, Memorystore, regional Persistent Disk.
• Multi-region or dual-region: Cloud Storage multi-region and dual-region buckets, Spanner multi-region configurations, BigQuery multi-region datasets, Firestore multi-region.
• Global: external Application Load Balancer, VPC networks, IAM, Cloud DNS.

Put compute close to users and to the data. Cross-region calls add tens to hundreds of milliseconds and cost egress. For zonal failover keep data replicated across zones (regional Cloud SQL, regional disks); for regional failover use cross-region replicas, multi-region Spanner or Firestore, or dual-region Cloud Storage (Turbo replication targets a 15 minute RPO).

Load balancers and session affinity

Backends can be instance groups, network endpoint groups (zonal NEGs for GKE pods, serverless NEGs for Cloud Run, functions and App Engine, internet NEGs for external origins) and Cloud Storage buckets. A serverless NEG is how you put Cloud Armor, Cloud CDN, custom domains and multi-region routing in front of Cloud Run.

Session affinity sends a client’s requests to the same backend. Options include generated cookie, HTTP cookie, header field, client IP and (for passthrough) 5-tuple variations. Use it when an instance holds local state worth reusing (caches, websocket-like flows). It is a performance aid, not a guarantee: affinity breaks when a backend becomes unhealthy or scales in. Truly shared session state belongs in Memorystore or a database, not in the instance. Cloud Run also has a session affinity setting (cookie-based, best effort).

Caching with Memorystore

Memorystore is the managed in-memory store: Memorystore for Redis (and Redis Cluster), Memorystore for Valkey, and Memorystore for Memcached. Pick Redis or Valkey for rich data types, persistence options and replication; Memcached for a simple distributed cache.

• Pattern: cache-aside. Read the cache; on a miss read the database, then write the cache with a TTL. Invalidate or expire on writes.
• Basic tier has no replica; Standard tier has a replica with automatic failover.
• It has a private IP in your VPC. Cloud Run reaches it through Direct VPC egress (or a Serverless VPC Access connector); GKE and Compute Engine connect directly.
• Use it for session data, hot lookups, rate-limit counters and leaderboards. Other cache layers: Cloud CDN for static and cacheable HTTP responses at the edge, and client-side or in-process caches for tiny data.

Creating and exposing APIs

• REST over HTTP/JSON is the default for public APIs. gRPC (Protocol Buffers over HTTP/2) fits low-latency internal service-to-service calls and streaming. Cloud Run, GKE and the Application Load Balancer support gRPC (Cloud Run needs HTTP/2 end-to-end enabled).
• API Gateway: a lightweight managed gateway in front of Cloud Run, Cloud Run functions or App Engine backends. Defined by an OpenAPI spec; supports API keys, JWT validation and Google ID tokens, with Cloud Monitoring and Logging.
• Apigee: the full API management platform: API proxies with policies, quotas and spike arrest, OAuth 2.0, API products, developer portal, monetization, analytics, multi-environment promotion. Choose Apigee when the question mentions monetization, partners, developer portal, complex transformation or enterprise governance.
• Cloud Endpoints is the older option (ESPv2 proxy). Treat it as legacy next to API Gateway.

Rate limiting in Apigee uses the Quota policy (per app or developer over a period) and Spike Arrest (smooths bursts). Return 429 when exceeded; clients back off.

Asynchronous and event-driven integration

Decouple producers from consumers so spikes are absorbed and failures are isolated.

Pub/Sub vs Cloud Tasks: Pub/Sub publishers do not know the consumers (fan-out); Cloud Tasks targets one specific handler and gives control over dispatch rate, scheduled time and task names (named tasks de-duplicate). Use Workflows when order, branching and compensating steps matter; use choreography (events) when services should stay independent. Pattern: Scheduler triggers a Workflow, which calls services and enqueues Cloud Tasks.

Resource requirements and cost

• Define CPU and memory per workload: Cloud Run per instance; GKE as pod requests (used for scheduling, and for billing on Autopilot) and limits; Compute Engine through machine type.
• Measure, then right-size. Use Cloud Monitoring and recommendations rather than guessing.
• Cost levers: scale to zero on Cloud Run, request-based CPU, committed use discounts for steady load, Spot VMs or Spot pods for fault-tolerant batch, Autopilot to pay for pods rather than idle nodes, storage classes and lifecycle rules, caching to cut database load, regional placement to cut egress.
• Trade-off: min instances remove cold starts but cost money while idle.

Traffic splitting strategies

• Cloud Run splits traffic between revisions by percentage. Deploy with --no-traffic and a tag to get a test URL, then move 1%, 10%, 50%, 100% (gcloud run services update-traffic SERVICE --to-revisions REV=10,REV2=90). Rollback is a one-line traffic change back to the previous revision; revisions are immutable. Splitting by percentage is random per request, so use tagged URLs when you need a specific tester on the new version.
• GKE: a rolling update replaces pods gradually (maxSurge, maxUnavailable). Canary can be two Deployments behind one Service with a replica ratio, or weights in Gateway API HTTPRoutes, or a Cloud Deploy canary strategy. Roll back with kubectl rollout undo.
• A/B testing sends defined user groups to different versions (by header, cookie or tag) and compares metrics; canary sends a small percentage to confirm health.

Designing secure applications

Data retention in Cloud Storage

• Object Lifecycle Management rules change storage class or delete objects by age, creation date, number of newer versions or state.
• A retention policy blocks deletion or overwrite of objects for a minimum period. Locking the policy (bucket lock) makes it permanent: it can be extended but never shortened or removed, and the bucket cannot be deleted until objects age out. Use it for WORM and compliance. Object holds (event-based or temporary) freeze individual objects.
• Object Versioning keeps old generations; soft delete (default 7 days) recovers deletions.
• Org policy constraints (for example, restricting locations or service account key creation) enforce rules across projects.

Finding and fixing vulnerabilities

• Identity-Aware Proxy (IAP) puts identity-based access in front of web apps on Cloud Run, App Engine, load balancers, GKE and Compute Engine without a VPN. Users need roles/iap.httpsResourceAccessor; the app should verify the signed IAP JWT header.
• Web Security Scanner (part of Security Command Center) crawls a deployed app for XSS, mixed content, outdated libraries and similar issues.
• Artifact Analysis scans images in Artifact Registry for known CVEs (on push and continuously) and stores metadata and provenance. Security Command Center aggregates findings across the organization. Fix by patching the base image, rebuilding, redeploying, and gating with Binary Authorization.

Secrets, keys and authentication

Avoid service account keys. Order of preference: attached service account, impersonation (roles/iam.serviceAccountTokenCreator), Workload Identity Federation, and only last a key. Service-to-service calls to a private Cloud Run service use a Google-signed ID token whose audience is the service URL, and the caller needs roles/run.invoker.

IAM, network and supply chain

• Least privilege: one dedicated service account per workload, narrow predefined or custom roles, grant on the smallest resource scope. Never use the default Compute Engine service account with Editor for production.
• Service-to-service: Cloud Service Mesh (managed Istio) for mTLS, authorization policies and telemetry; Kubernetes NetworkPolicies to restrict pod traffic; Direct VPC egress for Cloud Run to reach VPC resources; Private Service Connect and Private Google Access to reach Google APIs and published services privately; VPC Service Controls for data exfiltration perimeters.
• Binary Authorization is a deploy-time control for GKE and Cloud Run: a policy requires that images carry attestations from trusted attestors (signed with Cloud KMS keys), for instance “built by Cloud Build” and “passed tests”. It supports dry-run mode, break-glass override and continuous validation of running workloads.

Storing and accessing data

Choosing a store

Schema design

• Spanner: avoid monotonically increasing primary keys (timestamps, sequences), which hotspot one split. Use UUIDv4, bit-reversed sequences or hashed prefixes. Use interleaved tables or foreign keys to keep parent and child rows together. Add secondary indexes for non-key queries.
• Bigtable: the row key is the only index. Design keys for your main query; avoid hotspots from sequential keys; use field promotion, salting or reversed timestamps; prefer tall and narrow tables for time series; group columns into column families.
• Firestore: documents live in collections, can have subcollections; max document size 1 MiB; single-field indexes are automatic, composite indexes are required for multi-field queries with sorting or range filters; avoid sustained high write rates on one document. Denormalise to match read patterns.
• AlloyDB/Cloud SQL: normal relational design, indexes, connection pooling; use read replicas or read pools for read-heavy load.

Consistency

Signed URLs

A signed URL gives time-limited access to one Cloud Storage object to someone with no Google account. Sign with a service account (the signBlob API via IAM Credentials, or a private key) or an HMAC key. V4 signing allows up to 7 days. Use it for direct browser uploads and downloads so large files bypass your servers; signed policy documents constrain browser form uploads. Anyone holding the URL can use it until it expires, so keep expiry short.

Writing to BigQuery