I85PREP
⌘ K
GCP ACE study materials
GCP ACE study resources

A latency SLO, a cacheable API, and a data-residency rule that fights both

GCP ACE · Put your knowledge to work in context.

All case studies

A latency SLO, a cacheable API, and a data-residency rule that fights both

Playback Analytics runs a REST API on Compute Engine behind an external passthrough Network Load Balancer in us-central1; p99 latency for Sydney users is 210 ms against a 150 ms target. About 80% of responses are byte-identical for roughly 60 seconds and are safe to cache. The same team runs a nightly transcoding fleet: 40 workers, about 3 hours per job, and roughly 5% of workers are lost to host maintenance each night; workers already checkpoint to Cloud Storage every 5 minutes. The finance owner refuses committed use discounts because traffic may shift regions next year. A new compliance rule says all customer data must remain stored and processed in the United States, while the API must keep serving users worldwide.

1. Choose the load-balancing and caching architecture to get Sydney p99 under 150 ms, and explain why simply moving to a global external Application Load Balancer is not enough.

Read the worked answer

A global external Application Load Balancer terminates TLS at the POP nearest Sydney, which removes one or two round trips of handshake, but a cache miss still crosses the Pacific to the us-central1 backend at roughly 160 to 180 ms RTT. On its own it cannot hit 150 ms.

The two real levers, in this order:

  1. Cloud CDN on the global ALB backend, with an explicit cache key and Cache-Control: public, max-age=60. The 80% repeated responses are then served from the Sydney edge in single-digit milliseconds. Match the TTL to the stated 60-second repeat window; a longer TTL adds staleness without buying hit rate, and Vary on a header the client randomises will destroy the hit rate. Verify with CDN logs rather than assuming, because a low hit rate looks identical to a network problem.
  2. Proximity for the remaining 20%. A cache miss and every uncacheable response still pay the transpacific RTT, so the only fix is a backend closer to the user.

But read the next task before you build step 2, because a POP outside the United States may itself breach the residency rule, in which case step 1 is off the table and the SLO has to be renegotiated.

2. Choose a compute strategy for the transcoding fleet and justify it against the 5% nightly loss, the checkpoint interval, and the ban on committed use discounts.

Read the worked answer

The workload has already been designed for interruption: 5-minute checkpoints and 3-hour jobs. That is exactly the shape Spot VMs exist for, and the discount (up to roughly 91%) dwarfs anything a CUD would buy.

  • Spot VMs inside a regional MIG, with work pulled from a queue (Pub/Sub with leases) rather than statically partitioned. When a worker disappears, its lease expires and the chunk returns to the queue; a static partition would strand that work until someone noticed.
  • Make the checkpoint idempotent. Write the checkpoint to a temporary object and compose/rename on completion, so a retry mid-write cannot produce a corrupt or duplicate output.
  • Do not buy a CUD. The stated constraint is that traffic may shift regions; a one-year commitment is a bet against exactly that, and the commitment attaches to a region.
  • Consider Cloud Batch instead of hand-rolling the MIG: it handles queueing, retries, and Spot reclaim, and it is less code to own.

Accepting 5% nightly loss is not a risk here, it is the price signal. The design goal is that no single loss costs more than 5 minutes of work.

3. Reconcile the US-only residency rule with the requirement to serve global users. What do you build, and what do you refuse to build?

Read the worked answer

Storage and processing stay in United States locations: BigQuery US multi-region, GCS US buckets, Cloud SQL in a US region. That part is uncontroversial.

The conflict is at the transport layer. Any architecture where a non-US POP holds a cached copy of a response, or a non-US instance holds rows in memory, is arguably processing customer data outside the US, and the audit trail will show exactly that.

Options, cheapest first:

  1. No CDN, single US region, renegotiate the 150 ms SLO for APAC. Fully compliant, cheapest, and forces the business to price the latency requirement honestly.
  2. Cache only non-identifying aggregates at the edge, and prove to the auditor that the cached objects contain no customer data. This is a genuine engineering option, not a loophole, but it needs the data classification written down.
  3. Get the rule clarified in writing before architecting around it.

What you refuse to build: a stateless API in asia-southeast1 that queries US BigQuery. The compute is abroad, the data is processed abroad, and no amount of IAM tightening changes that. If the rule hardens, Assured Workloads is the next conversation.