A legacy inspector-scheduling database in the public-works account is overwhelmed by repeated reads of hot keys such as open time slots and session data after more field tablets came online. Which modernization enhancement should architects add without a full schema rewrite?
Select an answer to reveal the explanation.
Short Explanation
If the same open-slot row gets asked a thousand times, that's a sticky note on the counter, not another trip to the filing room. ElastiCache holds those hot keys so the old database can breathe. A bigger box still answers the same chatty questions.
Full Explanation
A legacy inspector-scheduling database in the public-works account overwhelmed by repeated reads of hot keys such as open time slots and session data after more field tablets came online should add Amazon ElastiCache in front of the chatty legacy database for hot keys and session cache without a full schema rewrite. Caching is the modernization enhancement that protects the legacy DB under tablet growth. Doubling the RDS instance class only and leaving every hot key hitting the database fails to address read amplification and scales cost linearly. Disabling all application caching so the database remains the only source of truth for every page fails performance under field load. Exporting the live schedule to Amazon S3 Glacier Deep Archive and querying it for each tablet refresh fails latency for live scheduling. Exam caveat: ElastiCache for hot keys is preferred over blind vertical scale when chatty reads dominate. Operational check: identify hot keys, introduce cache-aside with TTLs, invalidate on schedule changes, measure DB CPU drop, and keep DB as system of record for writes. Document the decision in the municipal architecture decision record and re-verify controls after the first production wave so auditors see continuous improvement, not one-time tribal knowledge.