Read-heavy catalog queries are overwhelming the primary Amazon RDS database for a city services directory. Writes remain modest. How should the architect scale reads?
Select an answer to reveal the explanation.
Short Explanation
When everyone is browsing the catalog, give them read replicas and keep the primary for writes. Shrinking the primary or deleting indexes makes the traffic jam worse, not better.
Full Explanation
Read-heavy catalog queries overwhelming the primary Amazon RDS database for a city services directory—while writes remain modest—should be scaled with RDS read replicas (or Aurora replicas). Direct read-only catalog traffic to the replicas and keep writes on the primary. That pattern multiplies read capacity without forcing an immediate vertical upsizing of the writer and fits civic directories where browsing dominates updates. Application connection routing (or reader endpoints on Aurora) must consciously separate read paths from write paths so reporting does not starve transactional updates.
Deleting indexes on the primary to force full table scans makes every query worse and is the opposite of performance engineering. Moving the primary to a smaller instance while keeping all reads on it reduces capacity under load and worsens contention. Disabling Multi-AZ and routing all traffic through one Availability Zone removes resilience without solving read scale; Multi-AZ standby is not a read replica for general query offload on standard RDS.
Exam caveat: read replicas scale reads; Multi-AZ is primarily for high availability of the primary, not read scaling (Aurora reader endpoints are the Aurora-specific read scale story—still, replicas/readers are the correct answer here). Operational check: create a replica, point catalog queries at the reader endpoint, verify replication lag under load stays within SLA, and keep write paths on the primary endpoint only.