Cache-aside pattern in HLD - System Design Guide

Problem Statement

When a system reads data directly from a slow database for every request, response times increase and the database can become overloaded under high traffic. This leads to poor user experience and potential downtime during traffic spikes.

Solution

The cache-aside pattern solves this by having the application check a fast cache first before querying the database. If the data is missing in the cache, the application loads it from the database and then stores it in the cache for future requests. This reduces database load and improves response times by serving frequent reads from the cache.

Architecture

Client

→Application

↓

Database

This diagram shows the client sending requests to the application, which first checks the cache. On a cache miss, the application queries the database and updates the cache before responding.

Trade-offs

✓ Pros

→

Reduces database load by serving frequent reads from cache.

→

Improves response times for cached data.

→

Simple to implement without requiring cache to be always consistent.

→

Allows selective caching of hot data.

✗ Cons

→

Cache can become stale if data changes frequently and cache invalidation is not handled.

→

Cache miss adds latency due to extra database query.

→

Requires application logic to manage cache reads and writes.

Use when read traffic is high and data can tolerate some staleness, typically over 1000 requests per second. Suitable when database is a bottleneck and caching hot data improves performance.

Avoid when data must always be strongly consistent or when write traffic is very high causing frequent cache invalidations that negate caching benefits.

Real World Examples

Amazon

Amazon uses cache-aside to reduce database load for product catalog reads, improving page load times during high traffic sales events.

Netflix

Netflix applies cache-aside to cache user session data and movie metadata, reducing latency and database stress during peak streaming hours.

Twitter

Twitter uses cache-aside to cache user timelines and tweets, enabling fast read access while keeping the database scalable.

Alternatives

Write-through cache

Cache is updated synchronously on every write, ensuring cache and database are always consistent.

Use when: Choose when strong consistency between cache and database is required and write latency overhead is acceptable.

Read-through cache

Cache automatically loads data from the database on a cache miss without application intervention.

Use when: Choose when you want to simplify application code by delegating cache loading to the caching system.

Write-back cache

Writes are made to cache first and asynchronously persisted to the database later.

Use when: Choose when write performance is critical and eventual consistency is acceptable.

Summary

Cache-aside pattern reduces database load by having the application load data into cache on demand.

It improves read performance by serving frequent requests from a fast cache while falling back to the database on misses.

This pattern requires application logic to manage cache reads, writes, and invalidations to avoid stale data.