Interview › Databases & Caching
How do you keep a cache and database consistent?
Databases & Caching · Advanced level
Answer
I keep cache and DB consistent by treating the DB as source of truth, using TTLs, invalidating after commits, versioning keys, and using outbox-driven invalidation so cache events are not lost.
Technical explanation
Database should remain the source of truth unless the cache is intentionally designed as a datastore.
Keep cache and DB consistent through TTLs, delete-after-commit, versioned keys, outbox-driven invalidation, and primary reads after writes.
Graceful degradation requires low cache timeouts, circuit breakers, stale-if-safe responses, DB fallback limits, and cache warming.
Hands-on example
Outbox invalidation example:
BEGIN;
UPDATE products SET price = 19.99 WHERE id = 123;
INSERT INTO outbox(event_type, payload) VALUES ("ProductUpdated", "{id:123}");
COMMIT;
Worker reads outbox, DEL product:v2:123, publishes event, marks outbox processed.
Warm top keys after failover with a throttled job and stop if RDS CPU or app latency rises.
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?