Hot fee-schedule reads hammer Aurora during business hours for a city cashiering app. What application-level change reduces database load?
Select an answer to reveal the explanation.
Short Explanation
Fee schedules barely change by the minute, but cashiers hit them constantly—classic cache win. Park the hot reads in ElastiCache and let Aurora breathe. Same answers, far less database thrash.
Full Explanation
Hot fee-schedule reads that hammer Aurora during business hours for a city cashiering app should be mitigated at the application level by caching those hot reads in ElastiCache (or equivalent) so repeated lookups avoid Aurora. Fee schedules change rarely relative to lookup volume; caching cuts database load while cashiers keep sub-second responses at peak.
Running a full Aurora table scan on every cashier keystroke maximizes database load and is the opposite of optimization.
Turning off the database during business hours to force static HTML fees breaks dynamic cashiering workflows.
Replacing all reads with synchronous cross-Region Aurora clones per request multiplies latency and cost without solving hot-read pressure.
Exam caveat: Cache hot, relatively stable reference data to protect relational databases under civic peak load.
Operational check: Introduce an ElastiCache layer for fee-schedule keys with an appropriate TTL, measure Aurora CPU/read IOPS decline during a cashiering load test, and define a cache invalidation path for scheduled fee updates. Keep the civic/municipal context in mind: morning cashier peaks can overwhelm Aurora if every terminal repeatedly reads the same fee tables.