Interview › Databases & Caching
Why are some Redis commands (KEYS, FLUSHALL) dangerous in production?
Databases & Caching · Advanced level
Answer
KEYS can block Redis by scanning the full keyspace, and FLUSHALL can delete the entire cache or datastore. In production I use SCAN/UNLINK, namespace isolation, ACL restrictions, and controlled cleanup jobs.
Technical explanation
Global hit ratio can hide bad key patterns; monitor by endpoint or key prefix where possible.
Large keys and hot keys can overload a single Redis thread or shard even when total cluster capacity looks fine.
Use SCAN and UNLINK instead of KEYS and mass DEL; restrict dangerous commands through ACLs or operational policy.
Hands-on example
Operational commands:
INFO stats
INFO memory
INFO commandstats
SLOWLOG GET 10
LATENCY LATEST
redis-cli --bigkeys -h <host> -p 6379
Safe cleanup pattern:
redis-cli --scan --pattern "session:*" | while read key; do redis-cli UNLINK "$key"; done
Pipeline warmup in batches instead of one command per network round trip.
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?