A municipal database VM that cannot easily shard is saturating CPU and RAM. Which short-term scaling approach fits best?
Select an answer to reveal the explanation.
Short Explanation
When you can’t easily split the filing cabinet, you buy a bigger cabinet—that’s vertical scaling. More CPU and RAM on the same database VM buys headroom when sharding isn’t practical yet. It’s not forever architecture, but it’s the right short-term lever.
Full Explanation
Vertical scaling that increases CPU and RAM on the existing database instance is the best short-term fit when a municipal database VM saturates resources and cannot easily shard. Cloning the database into dozens of independent writers with no coordination risks corruption and split-brain writes. Removing all indexes and hoping query load drops harms performance further. Shutting down the database nightly to free memory for morning reports creates unacceptable civic outages. Exam caveat: hard-to-distribute data tiers often need vertical scale short-term; horizontal multi-writer is not free. Operational check: resize the instance during a change window, watch CPU/RAM/IO, plan longer-term read replicas or redesign, and document the temporary nature for architecture review. In municipal platform operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand the failure modes avoided for citizen services. Re-check the decision after the next provider feature change or compliance update to ensure the same answer still holds for the city's estate. Confirm monitoring, access reviews, and backup coverage still align with the selected approach before closing the civic hypercare period.