SAA-C03 - Design High-Performing Architectures (24% of the exam) - Section 3.6

Improve database performance using caching and read scaling with Amazon ElastiCache, read replicas and DynamoDB Accelerator.

Describe Amazon ElastiCache for Redis and Memcached as in-memory caching layers that reduce read latency and offload repeated queries from backend databases. Compare lazy-loading and write-through caching strategies, explain how RDS and Aurora read replicas distribute read traffic across multiple instances, and identify DynamoDB Accelerator as a purpose-built in-memory cache for DynamoDB that delivers microsecond read response times.

Amazon ElastiCacheRead replicasDynamoDB AcceleratorCaching strategies

Practice question for this objective

Free sampleDesign High-Performing Architecturesmedium

A read-heavy product catalogue runs on a single Amazon RDS for MySQL instance. Most traffic is repeated lookups of the same popular items, and the rest is a growing volume of varied read-only queries that still hit the database directly. The primary's CPU is now saturated and writes are slowing. The team wants to relieve the primary by both serving repeated reads from memory and spreading the remaining varied reads across additional database capacity, without re-architecting onto a different database engine. Which two changes together meet these requirements? Select TWO.

AAdd Amazon DynamoDB Accelerator (DAX) as an in-memory cache in front of the RDS for MySQL instance to accelerate the repeated reads.
BConvert the instance to a Multi-AZ deployment and send the read-only queries to the standby instance.
CPlace an Amazon ElastiCache cluster in front of the database and serve the repeated popular-item reads from the in-memory cache. Correct
DCreate one or more RDS for MySQL read replicas and direct the varied read-only queries to the replica endpoints. Correct
EResize the single RDS instance to a much larger instance class so it can absorb all reads and writes on one node.

Combine an in-memory cache for repeated reads with read replicas for varied reads to offload a saturated relational primary without changing engines. Caching with ElastiCache removes repeated identical lookups by serving them from memory before they reach the database, while read replicas provide additional readable instances that absorb the remaining varied read-only queries; together they cut load on the writer and let it focus on writes. DAX caches only DynamoDB, a Multi-AZ standby is not readable, and a bigger single instance still concentrates all reads on one node.

Why A is wrong: DAX is tempting as an in-memory cache but only works with Amazon DynamoDB, so it cannot front an RDS for MySQL instance.

Why B is wrong: Multi-AZ adds a synchronous standby for failover only; the standby is not readable, so it adds no read-scaling capacity.

Why C is correct: An in-memory cache absorbs the repeated identical lookups so they never reach the primary, directly cutting its read load.

Why D is correct: Read replicas add separate queryable capacity, letting the application spread varied reads off the primary while writes stay on the writer.

Why E is wrong: Scaling up vertically gives a brief headroom boost but keeps every read on one node and does not offload repeated or varied reads.

See more SAA-C03 practice questions, answers explained.

Exam traps in Design High-Performing Architectures

Answers that look right on this material and are not. Each one is a distractor from a different question in the SAA-C03 bank for this domain.

Increase the provisioned read capacity units on the DynamoDB table substantially so the table itself can absorb the millions of repeated reads at peak.
Why it is wrong: Raising read capacity stops throttling and scales throughput, but DynamoDB reads stay in the single-digit millisecond range, so this cannot deliver the microsecond latency the scenario requires for the hot keys.
Keep lazy loading but shorten the time to live on every cached session so entries refresh more frequently and stale data is evicted sooner from the cache.
Why it is wrong: A shorter time to live only changes how soon entries expire and would actually cause more misses, so it does nothing to make the very first read of a freshly written session a cache hit.
Promote a new Amazon RDS read replica and direct every catalogue read query to the replica endpoint so the writer instance is left to handle only writes.
Why it is wrong: A read replica spreads read load across more database instances, but it still answers each query from disk-backed storage rather than memory, so repeated identical lookups are not served from an in-memory cache as the requirement asks.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.