A city 311 portal team plans to insert a new Amazon ElastiCache layer in front of a hot RDS read path. Leadership wants the change promoted only after proving it under realistic citizen-traffic patterns. Which remediation approach best meets that continuous-improvement gate?
Select an answer to reveal the explanation.
Short Explanation
New caches look shiny until Black Friday—or tax-deadline Monday—hits the 311 phones. Stage a dress rehearsal with real-ish load, then promote the winner. Skipping the load test is how you invent a citizen outage.
Full Explanation
Inserting Amazon ElastiCache in front of a hot RDS read path on a city 311 portal should be promoted only after proving behavior under realistic citizen-traffic patterns. Load-testing the proposed cache topology and key strategy in pre-production against recorded or synthetic 311 traffic, then promoting only candidates that meet latency and error budgets, meets that continuous-improvement gate. That remediation approach works because caches can amplify stampedes, miss storms, or wrong TTLs—evidence before production protects residents. Deploying the cache straight to production during lunch and watching social media fails as uncontrolled experimentation on citizens. Disabling CloudWatch metrics on RDS so cache hit rates cannot create alarms fails conceptually by removing the very signals needed to validate the change. Replacing RDS with a single shared EBS volume mounted to every web host fails as an unsuitable shared-disk architecture for the relational path. Exam caveat: load tests must include cold-cache and failover cases; a warm-cache-only test overstates benefit and hides thundering herds after node replacement. Operational check: build a pre-prod cache with production-like keys, replay peak 311 read traffic, compare p99 and error budget to baseline, document eviction/TTL choices, and only then promote behind a feature flag.