A media company runs a product-catalogue API backed by Amazon RDS for PostgreSQL with a Multi-AZ primary and two read replicas. During campaigns a small set of popular item records is read thousands of times per second, the replicas approach their CPU limit, and read latency rises even though the data changes only a few times an hour. The team needs to absorb this repeated read traffic and cut tail latency to single-digit milliseconds with minimal application change and the lowest added cost. Which approach MOST effectively meets the requirement?
- AAdd several more Amazon RDS for PostgreSQL read replicas behind a load balancer and spread the campaign read traffic across the enlarged replica fleet to lower the per-replica request rate during peaks.
- BMigrate the catalogue to Amazon DynamoDB with DynamoDB Accelerator enabled so the hottest item reads are served from the in-memory accelerator instead of from the relational database during campaigns.
- CEnable Multi-AZ failover on each read replica and increase the instance class of the primary and replicas so the larger engines can hold more of the hot catalogue pages in their local buffer cache.
- DPut an Amazon ElastiCache for Redis cluster in front of the database and have the API lazy-load the hot item records into the cache so repeated reads are served from memory with a short time to live. Correct
Why A is wrong: More replicas raise read capacity but each request still hits a full database engine, so repeated reads of the same few records cost more standing infrastructure without delivering single-digit-millisecond cached latency.
Why B is wrong: DAX gives microsecond reads but only fronts DynamoDB, so it forces a full re-platform of a working relational catalogue, which is a large application change rather than the minimal one requested.
Why C is wrong: Larger instances and replica failover improve durability and headroom, but scaling the engines up is costlier and still serves every repeated read through the database rather than from a dedicated cache tier.
Why D is correct: A cache-aside ElastiCache layer serves the few repeated hot records from memory at single-digit-millisecond latency, offloads the replicas, and needs only a small read-path change with low incremental cost.