Caching Strategies: Lazy Loading and Write-Through

Inserting a cache between your application and database requires a caching strategy — a set of rules that determine when data is put into the cache, when it is read from the cache, and when it is evicted. Choosing the wrong strategy leads to either stale data (cache returns outdated values), cold cache misses (cache is empty and every request hits the database), or cache stampede (many simultaneous requests for the same missing key all hit the database simultaneously). The two foundational strategies are lazy loading and write-through.

Lazy loading (also called cache-aside) is the most common caching pattern. The application checks the cache first. On a cache hit, data is returned directly from the cache — fast path. On a cache miss, the application fetches data from the database, writes the result into the cache with a TTL, and returns it to the caller. The cache is only populated with data that is actually requested — hence 'lazy'. The next request for the same key will find it in the cache.

Lazy loading has three key advantages: only requested data is cached — the cache is not filled with data nobody reads, so memory is used efficiently. A cold cache does not break the application — on cache misses the application falls back to the database, so even if ElastiCache is restarted or a node fails, the application continues to work (with higher latency). Cache is always eventually consistent with the database because stale data expires via TTL even if updates were missed.

Lazy loading has three key disadvantages: cache misses are expensive — three operations (cache check, database read, cache write) versus one for a hit, causing higher latency for cold requests. Stale data — after a database update, the cache still serves the old value until TTL expires or the key is explicitly invalidated (cache inconsistency window). Cache stampede — if a popular key expires, many simultaneous requests all experience a cache miss and hit the database concurrently, potentially overwhelming it.

In the write-through strategy, every write to the database is also written to the cache simultaneously. The application writes to both the cache and the database as part of the same operation (or the database triggers a cache update). The cache is therefore always in sync with the database — there is no stale data window. Write-through guarantees that data in the cache is always up-to-date, making subsequent reads always cache hits for recently written data.

Write-through advantages: cache data is always fresh — no stale data because the cache is updated on every write. Reads are always fast — popular data that is written frequently is always in the cache. No cache stampede on reads — because data is pre-populated before it is read, there are no cold misses for recently written data. This strategy is ideal for read-heavy workloads with frequent updates where data freshness is critical, such as product catalogs, pricing systems, or user profile caches.

Write-through disadvantages: write penalty — every write incurs two operations (database + cache), adding latency to writes. Cache pollution — data is cached even if it is never read again (written once, never requested), wasting cache memory. Cache restart means cold cache — if the cache cluster is restarted, all the proactively written data is lost and the cache must be re-populated through writes or a cache warm-up process. Combine write-through with a TTL to prevent unbounded growth of rarely-read cached data.

In practice, many production systems combine both strategies: use write-through for frequently updated, frequently read data (like user sessions or current prices) and lazy loading for rarely updated, frequently read data (like product descriptions or article content). Set appropriate TTLs on both: write-through keys get a long TTL since data is always fresh; lazy-loaded keys get a shorter TTL to bound the stale data window. This hybrid approach maximises cache hit rate while minimising staleness.

The Time-To-Live (TTL) on cached data controls the maximum stale data window and the cache's memory footprint. Design TTLs based on: data update frequency (session data changes often → short TTL; static content changes rarely → long TTL), staleness tolerance (financial prices → very short; blog post text → hours or days), and cache memory capacity (low memory → shorter TTL to evict stale data faster). Always set a TTL — never cache data without expiry or the cache will eventually fill with stale data.

Instead of relying solely on TTL expiry, you can explicitly invalidate (delete) cache keys when the underlying data changes. This eliminates the stale data window entirely. Common patterns: delete-on-write (delete the cache key after every database update — the next read repopulates via lazy loading), event-driven invalidation (DynamoDB Streams or RDS change capture triggers a Lambda that deletes affected keys). Cache invalidation is one of the hardest problems in distributed systems; the simpler the invalidation logic, the more reliable your cache.

A less common but powerful pattern is write-behind (write-back): the application writes only to the cache, and the cache asynchronously flushes data to the database in the background. This gives extremely fast writes (in-memory only) at the cost of potential data loss if the cache fails before flushing. Write-behind is appropriate for high-frequency, high-volume writes where the data can be reconstructed or small losses are acceptable — such as hit counters, analytics events, or gaming score updates. ElastiCache does not natively support write-behind; it must be implemented at the application layer.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: lazy loading populates the cache on read misses and uses memory efficiently but can serve stale data until TTL expires, write-through updates the cache on every write for zero stale data but wastes memory on unread data, and explicit invalidation deletes cache keys on database updates to eliminate stale windows. Next up we explore session storage and leaderboard patterns with ElastiCache.