Interview › Databases & Caching
How do you test a Redis or database failover without impacting users?
Databases & Caching · Advanced level
Answer
I test database or Redis failover through staging and approved game days, measuring application recovery, reconnect behavior, error rate, latency, and alerting. The complete app path matters more than the service event alone.
Technical explanation
Failover testing must include clients, retries, DNS/endpoints, connection pools, and alerts.
Staging comes first; production tests need approval, abort criteria, and rollback ownership.
Success is measured by application recovery, not only the managed-service event completing.
Hands-on example
Game day:
Pre-check backups and replicas.
Trigger RDS or ElastiCache failover in a controlled window.
Watch p95 latency, 5xx, reconnect logs, DB/cache metrics, and alerts.
Pass if app recovers without manual pod restart.
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More Databases & Caching interview questions
- What is Amazon RDS, and what does it manage for you versus self-managed databases?
- What database engines does RDS support?
- What is the difference between RDS and Aurora?
- What is Multi-AZ in RDS, and how does automatic failover work?
- How long does an RDS Multi-AZ failover typically take, and what triggers it?
- What is the difference between Multi-AZ and a read replica?
- When would you use a read replica, and can it become a standalone database?
- Can a read replica be in a different region, and why would you do that?