A county property-search site is read-heavy against Amazon RDS and frequently repeats the same queries. How should the architect improve database read performance?
Select an answer to reveal the explanation.
Short Explanation
Repeating the same property lookups shouldn’t hammer the database every time—cache them. ElastiCache in front of RDS soaks up those hot reads and protects the DB. Killing indexes, parking the DB on instance store, or making every read a write path goes the wrong way.
Full Explanation
Read-heavy county property search that repeats the same RDS queries should absorb hot reads in an in-memory cache. Placing Amazon ElastiCache in front of RDS stores frequent property-search results so citizen lookups hit cache first, cutting latency and shielding the database from repetitive load. That cache-aside (or comparable) pattern is the Task 3.3 high-performing database approach for repeated municipal search traffic. Deleting RDS indexes so every search performs a full table scan fails because removing indexes increases I/O and latency—the opposite of improving read performance. Moving the primary database to instance store on a single web host fails conceptually: instance store is ephemeral and local, unsuitable as the durable primary for county property data, and collapses HA. Forcing all reads through multi-AZ synchronous writes only fails because conflating read acceleration with the synchronous write path does not create a cache and can increase contention rather than speeding repeated searches. Exam caveat: caching improves repeated reads but requires TTL and invalidation when parcel data changes; stale cache entries can mislead citizens if updates are not invalidated. Operational check: identify the hottest property-search queries, cache them in ElastiCache with a documented TTL, measure RDS CPU and query latency before and after, and verify update paths invalidate or refresh affected keys.