What the exam asks
- Choose the layer. Edge (CloudFront), API (API Gateway cache), application memory, or database (ElastiCache, DAX).
- Choose the pattern. Lazy loading or write-through, with a TTL, and predict what becomes stale or cold.
- Choose the engine. ElastiCache for Valkey/Redis OSS or for Memcached, or DAX for DynamoDB.
- Choose between a cache and a read replica for an overloaded relational database.
Core ideas
Where to cache
| Layer | Service | Best for | Keyword |
|---|---|---|---|
| Edge | CloudFront | Static files and cacheable HTTP responses for global users | “global users”, “reduce origin load” |
| API | API Gateway stage cache (REST APIs) | Identical GET requests to an API | “same requests”, “fewer Lambda invocations” |
| Application | In-memory variables (for example Lambda code outside the handler) | Config or reference data that rarely changes | “every invocation”, “throttled parameter calls” |
| Database | ElastiCache | Query results, sessions, leaderboards, computed objects | “sub-millisecond”, “repeated queries” |
| Database | DAX | DynamoDB items and queries | “microsecond”, “DynamoDB”, “minimal code change” |
Cache as close to the user as the data allows. Personalised or rapidly changing data must be cached further back, or its cache key must include whatever makes it unique.
Caching patterns
| Pattern | How it works | Pros | Cons |
|---|---|---|---|
| Lazy loading (cache-aside) | Read the cache. On a miss, read the database and write the result to the cache |