Caching and Database Scaling
Caching with CloudFront and ElastiCache, scaling RDS and Aurora with replicas and serverless capacity, and DynamoDB capacity modes with DAX.
Every database eventually hits a request it cannot answer fast enough, and there are only two honest responses: stop asking the question, or make the thing that answers it bigger. Caching is the first. Scaling the database is the second. This topic covers both, and the judgment call that comes before either one: naming exactly what is repeating, and where, before you add a service to absorb it.
What This Topic Covers
- Where an edge cache helps and where it cannot: the CloudFront cache key, cache policies and their managed presets, and why fewer values in the key means more hits
- How CloudFront decides an object's lifetime, clamping the origin's
Cache-Controlheaders between the policy's minimum and maximum TTL, and the minimum-TTL setting that quietly overridesno-store - Invalidation costs and limits against versioned file names, plus Origin Shield and the other cache hit ratio levers
- ElastiCache population strategies (lazy loading, write-through, and TTL), the failure each one carries, and the engine differences that decide which scaling actions exist
- Reading ElastiCache metrics to choose between a larger node, more replicas, and more shards, including the single-threaded CPU threshold arithmetic
- The boundary between a Multi-AZ standby, an RDS read replica, and an Aurora Replica, and why only two of the three can serve a query
- RDS storage autoscaling conditions and increments, RDS Proxy for connection pressure, and the shared cluster volume that changes Aurora's rules
- Aurora Auto Scaling, reader and custom endpoints, and Aurora Serverless capacity in ACUs
- DynamoDB capacity unit arithmetic, on-demand against provisioned with auto scaling, burst and adaptive capacity, and what DAX caches, passes through, and serves stale
Why It Matters
SOA-C03 Skills 2.1.2 and 2.1.3 are written as operational scenarios, not definitions. A table throttles while showing unused capacity. A personalized page appears at the wrong edge location. A reporting workload is pointed at a standby that cannot serve it. Each has one correct diagnosis and several plausible wrong ones, and telling them apart is the same skill that ends a real incident in minutes rather than hours.
