Caching • Cache Patterns (Aside, Through, Back)Medium⏱️ ~3 min
Read Through Pattern: Cache Managed Data Loading
Read through moves cache population responsibility from the application to the cache layer itself or a cache proxy adapter. The application always reads through the cache, which becomes a smart intermediary. On a cache miss, the cache layer automatically fetches data from the source of truth, populates itself, and returns the result to the caller. This centralizes miss handling logic, request coalescing (combining multiple concurrent requests for the same key), and advanced features like refresh ahead, where entries near expiry are proactively refreshed in the background to maintain low latency for steady traffic patterns.
Amazon's DynamoDB Accelerator (DAX) implements read through as a managed service. AWS reports read latency improvements from single digit milliseconds (typical DynamoDB read) to microseconds with DAX on cache hits, often a 10x reduction. With hit ratios above 80 to 90% for read heavy workloads with temporal locality, this translates to similar reductions in DynamoDB Read Capacity Units (RCUs) and direct cost savings. The DAX SDK talks to the DAX cluster for all reads, and DAX handles fetching from DynamoDB on misses transparently. Writes can also go through DAX in write through mode, where they are persisted synchronously to DynamoDB before acknowledgment, yielding consistent read after write semantics via the cache.
The primary trade off is operational coupling to a smart cache tier that must handle failure isolation and backpressure. Read through is operationally simpler for application teams since they no longer write miss handling code, but it requires robust cache infrastructure. The cache layer must implement circuit breakers and bulkheads to protect the source database. When the source is degraded, advanced implementations serve slightly stale data from cache for a bounded interval (stale while revalidate pattern) if business rules allow. Request coalescing prevents duplicate fetches when many clients miss the same key simultaneously, but the cache layer must carefully manage these in flight requests to avoid holding connections open too long.
💡 Key Takeaways
•Cache layer owns fetching on miss: application always reads through cache, which loads from source and self populates transparently
•Amazon DynamoDB Accelerator delivers 10x latency reduction from single digit milliseconds to microseconds on hits, with 80 to 90% hit ratios for temporal locality workloads
•Request coalescing built into cache layer prevents duplicate fetches when concurrent clients miss the same key, reducing load on source database
•Refresh ahead feature proactively refreshes entries approaching TTL expiry in background, maintaining sub millisecond latency for hot keys under steady traffic
•Requires robust cache infrastructure with circuit breakers, bulkheads, and backpressure handling since all miss traffic flows through cache tier
•Operational simplicity for application teams traded for tight coupling between cache and storage semantics; adapter bugs affect all consumers
📌 Examples
DynamoDB Accelerator (DAX) deployment: SDK configured with DAX endpoint instead of DynamoDB. On read, DAX checks local cache, fetches from DynamoDB on miss with sub 100 microsecond overhead, populates cache with configurable TTL. Application code unchanged from native DynamoDB SDK calls.
Netflix EVCache read through via client library: Library handles miss logic, batching, and cross AZ replication. Client calls evCache.get(key) which internally coalesces requests, fetches from backend if needed, writes to local and remote caches, returns value. Typical in AZ latency under 1 millisecond.
Refresh ahead implementation: Cache monitors access timestamps. When entry accessed within 20% of TTL expiry, schedule background task: newValue = database.query(key); cache.setIfNewer(key, newValue, ttl); This keeps hot keys perpetually fresh without user facing miss penalty.