A read-heavy open-data catalog hammers Aurora with identical queries for popular datasets. What application-level change reduces database load?
Select an answer to reveal the explanation.
Short Explanation
If everyone asks for the same popular dataset, stop poking the database every time—park the answer in ElastiCache and serve the crowd from memory.
Full Explanation
A read-heavy open-data catalog that repeats identical Aurora queries for popular datasets should cache hot results in the application tier with Amazon ElastiCache (Redis or Memcached). Serving repeated catalog pages from cache cuts database load, lowers latency for citizens browsing the same datasets, and keeps Aurora capacity focused on true cache misses and write paths instead of identical SELECT chatter.
Increasing Aurora storage to maximum IOPS while leaving every query uncached spends money on the database without removing duplicate read work at the application layer. Replacing Aurora with a single DynamoDB Scan for every catalog page is a regression in access-pattern design and Scan cost, not a caching strategy. Disabling Aurora reader endpoints so all traffic hits the writer removes read scaling and worsens contention on the primary—opposite of reducing load.
Exam caveat: cache-aside needs a TTL and an invalidation or versioning story so corrected dataset metadata does not linger after publishers fix a catalog entry; ElastiCache is not a substitute for durable Aurora as system of record. Operational check: enable cache hit/miss metrics, hit a popular dataset page repeatedly under load, confirm the hit ratio rises, and verify Aurora’s rate of identical catalog queries drops for the same traffic profile.