← Back to Gallery
💾
Cache-Aside Pattern
Definition
The Cache-Aside Pattern (also known as Lazy Loading) loads data into the cache on demand. The application first checks the cache. If data exists (cache hit), it's returned immediately. If not (cache miss), the application loads data from the data store, stores it in the cache, and returns it to the caller.
When to Use It
- Improving read performance for frequently accessed data
- Reducing database load
- Data is read more often than written
- You want to control what gets cached
- Reducing latency for end users
- Handling expensive computations or queries
Pros & Cons
✓ Pros
- Significantly improved read performance
- Reduced database load
- Lower latency for frequently accessed data
- Only caches requested data (efficient)
- Application controls cache logic
- Cache failures don't break the system
✗ Cons
- Cache and data store can become inconsistent
- First request is always slow (cache miss)
- Application must manage cache logic
- Requires cache invalidation strategy
- Additional infrastructure complexity
- Memory usage considerations
Architecture Diagram
Cache-Aside Flow
================
Read Operation (Cache Hit):
───────────────────────────
┌─────────────┐
│ Application │
└──────┬──────┘
│
1. │ GET user:123
▼
┌──────────────┐
│ Cache │
│ (Redis) │
│ │
│ user:123 ✓ │ ◄─── Data found in cache
└──────┬───────┘
│
2. │ Return data
▼
┌─────────────┐
│ Application │ ◄─── Fast response (no DB hit)
└─────────────┘
Read Operation (Cache Miss):
─────────────────────────────
┌─────────────┐
│ Application │
└──────┬──────┘
│
1. │ GET user:456
▼
┌──────────────┐
│ Cache │
│ (Redis) │
│ │
│ user:456 ✗ │ ◄─── Data NOT in cache
└──────┬───────┘
│
2. │ Cache Miss
▼
┌─────────────┐
│ Application │
└──────┬──────┘
│
3. │ Query database
▼
┌──────────────┐
│ Database │
│ (Postgres) │
│ │
│ user:456 ✓ │ ◄─── Fetch from source
└──────┬───────┘
│
4. │ Return data
▼
┌─────────────┐
│ Application │
└──────┬──────┘
│
5. │ SET user:456 (TTL: 3600s)
▼
┌──────────────┐
│ Cache │ ◄─── Store for next time
└──────────────┘
Write Operation (Cache Invalidation):
──────────────────────────────────────
┌─────────────┐
│ Application │
└──────┬──────┘
│
1. │ UPDATE user:123
▼
┌──────────────┐
│ Database │ ◄─── Update source of truth
└──────┬───────┘
│
2. │ Success
▼
┌─────────────┐
│ Application │
└──────┬──────┘
│
3. │ DELETE user:123
▼
┌──────────────┐
│ Cache │ ◄─── Invalidate cached data
└──────────────┘
Strategies:
• Write-through: Update cache on write
• Write-behind: Async update to cache
• TTL: Automatic expiration
• LRU: Least Recently Used eviction
Common Cache Implementations:
• Redis
• Memcached
• Amazon ElastiCache
• Azure Cache for Redis