Placement changes latency, ownership, and consistency#
A request may encounter several caches, but it does not need every layer shown below. Place a copy where it removes meaningful work without making correctness or invalidation unmanageable.
| Location | Latency | Shared? | Invalidation boundary | Good fit |
|---|---|---|---|---|
| Browser / client | Lowest | No | Client and HTTP policy | Reusable responses and assets |
| CDN / edge | Near user | Across regional users | HTTP freshness and purge | Cacheable HTTP/media |
| Reverse proxy | Before app | Across app instances | Proxy policy | Repeated HTTP responses |
| Application local | No network hop | No | Per process | Small hot reference data |
| Distributed | Network hop | Yes | Shared application policy | Large shared working set |
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Which requests can safely share one entry?
- Does the cache key include identity, locale, or authorization context?
- How are local copies invalidated across instances?
- Would a two-level local and distributed cache be worth the extra state?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Caching challenges and strategiesAmazon Builders' Library
- RFC 9111: HTTP CachingIETF / RFC Editor
Reach this point to mark the lesson as read.