Cache Consistency
Consistency Models
| Model | Description |
|---|---|
| Strong | Cache and DB always match |
| Eventual | Eventually consistent |
| Read-your-writes | You see your own writes |
Invalidation on Write
@Transactional
public Product updateProduct(Long id, UpdateRequest req) {
Product product = productRepository.save(...);
redis.delete("product:" + id); // Invalidate
return product;
}
Race Condition
Thread 1: Read from DB (price = $150)
Thread 2: Read from DB (price = $150)
Thread 1: Write to cache (price = $150)
Thread 2: Write to cache (price = $100) ← WRONG! Stale!
Fix: Use locks or single-writer pattern.
Cache Best Practices
Strategies
- Cache-Aside: Application manages cache
- Write-Through: Sync write to cache and DB
- Write-Behind: Async write to DB
- Read-Through: Cache loads from DB
Invalidation
- Time-based TTL
- Event-based invalidation
- Version-based keys
- Tag-based grouping
Monitoring
- Hit rate > 80% is good
- Monitor eviction rates
- Track cache size
- Alert on anomalies
Key Points
- Understanding Cache Consistency is essential for production systems
- Always consider scalability and maintainability
- Test thoroughly before deploying to production
- Monitor performance and set up alerting
Common Patterns
- Validation: Always validate input at the boundary
- Error Handling: Use structured error responses
- Logging: Log key events for debugging
- Testing: Unit, integration, and load tests
- Documentation: Keep docs updated with code changes
Practice Problems
Design and implement a solution for Cache Consistency in a backend system. Consider scalability, error handling, and production readiness.
Solution
// Cache Consistency implementation
// Key aspects: validation, error handling, logging, testing
public class CacheConsistency {
// Production-ready implementation
}Identify and handle edge cases for Cache Consistency. What happens under high load, with invalid input, or during failures?
Solution
// Edge case handling:
// 1. Null/empty input -> validation
// 2. High load -> rate limiting, queuing
// 3. Failures -> retries, circuit breaker
// 4. Concurrent access -> locks, idempotencyWrite a testing strategy for Cache Consistency. Include unit tests, integration tests, and performance tests.
Solution
// Test plan:
// - Unit: 80% coverage target
// - Integration: API contracts
// - Performance: latency, throughput
// - Chaos: failure injectionQuiz
1. Strong consistency means?
2. Race condition fix?
3. What is the primary purpose of Cache Consistency?
4. What is a common mistake when implementing Cache Consistency?
Flashcards
Question
Strong consistency?
Click to reveal answer
Answer
Cache and DB always match
Question
Race condition fix?
Click to reveal answer
Answer
Locks or single-writer pattern
Question
What is Cache Consistency?
Click to reveal answer
Answer
Cache Consistency is a key concept in backend development.
Question
When to use Cache Consistency?
Click to reveal answer
Answer
Use Cache Consistency when building production systems that require reliability, scalability, and maintainability.
Question
Cache Consistency best practices
Click to reveal answer
Answer
Follow SOLID principles, write clean code, test thoroughly, document decisions, and monitor in production.
Revision Notes
Key Takeaways
- 1.Strong: always matches, Eventual: eventually matches
- 2.Invalidate cache on write
- 3.Use locks to prevent race conditions
Interview Tips
- •Handle cache consistency
- •Prevent race conditions
Cheat Sheet
Cache Consistency
- Strong: always matches
- Eventual: eventually matches
- Invalidate on write
- Race conditions: locks or single-writer