Choose the right front door—and cache only safe data

Begin with one request. Record its protocol, caller identity, routing rule, response deadline, peak rate, backend capacity, and whether the answer may be stale. A service name comes later.

API Gateway manages REST, HTTP, and WebSocket APIs. An Application Load Balancer routes HTTP or HTTPS to VPC targets by rules such as host or path. Both can receive HTTP, but their product boundaries are different.

Ask whether the caller needs the work to finish before receiving a response. A quick read may stay synchronous. A request that starts minutes of processing can acknowledge acceptance and place work on a queue instead of holding every connection open.

Now classify the response. Public descriptions, personalized pages, inventory, prices, and entitlements do not share one freshness rule. Write the acceptable staleness and failure behavior for each class.

The authoritative source remains the database or service that owns the record. A cache stores a reusable answer; it does not become the owner merely because it responds faster.

Choose CloudFront when global HTTP delivery and edge caching reduce origin work. A cache hit can answer near the viewer. A miss still reaches the origin, so the origin must handle the uncached rate.

Choose Global Accelerator when traffic is noncacheable and needs static anycast IP addresses or improved network routing to healthy Regional endpoints. It routes traffic; it does not store an HTTP response.

Choose an Application Load Balancer for Layer 7 routing to application targets in a VPC. Choose API Gateway when the requirement is a managed API boundary. Stack services only when each owns a named job.

For example, CloudFront can cache public catalog descriptions before a restricted ALB origin. Adding Global Accelerator in front of that cacheable HTTP path does not create another cache. An ALB alone balances requests but does not provide edge caching.

Close bypass paths. If clients can call the origin directly, they can avoid the edge cache, request filtering, and other controls placed at CloudFront. Test the distribution URL and the origin address separately: the intended path should work and the direct path should fail.

A cache key must include every request property that changes the answer. If identity or authorization changes the response, omitting it can show one caller another caller's data.

Set time to live, invalidation after writes, eviction behavior, and the result of cache or source failure. Public descriptions may use a bounded stale response. Inventory and entitlements should reach their authority or fail closed when stale data could sell unavailable stock or grant revoked access.

Cache-aside reads the cache first, loads the source on a miss, then populates the cache. After a restart, many simultaneous misses can stampede the origin. Coalesce work, limit retries, and watch origin concurrency rather than edge latency alone.

A replicated cache can reduce node-loss impact, but cached data is not automatically a durable record. When the cache fails, the source of truth must still define correctness and recovery.

For the catalog, 12,000 reads each second exceed the origin's safe 2,000. Cache the public descriptions with a bounded TTL and restricted origin. Keep current inventory and entitlements on an authoritative path with stricter failure behavior.

Measure hit ratio, object age, origin request rate, p95 latency, and direct-origin rejection. The design passes only when origin load stays safe without serving a stale answer where correctness forbids it.