What are common caching strategies in system design?

Caching stores frequently used data somewhere faster to access than the original source of truth.

The goal is usually to reduce latency, reduce database load, absorb traffic spikes, and improve user experience.

Imagine a product page that gets thousands of requests per minute. Each request needs product details, pricing, inventory hints, review summaries, and recommendation data.

Without caching, every request may hit the database or multiple downstream services.

But caching creates new questions: how fresh does the data need to be, what happens when data changes, and what happens if the cache is down?

Suppose product details are read constantly but updated relatively rarely.

This is a perfect fit for cache-aside, also called lazy loading. In cache-aside, the application checks the cache first; on a miss, it reads from the database, stores the result in cache, and returns it. This is one of the most common database caching strategies.

Product getProduct(String productId) {
    Product cached = cache.get(productId);

    if (cached != null) {
        return cached;
    }

    Product product = database.findProduct(productId);
    cache.set(productId, product, ttl);

    return product;
}

Suppose users update their profile, and the next read should usually see the updated data.

One option is write-through caching. The application writes to the database and immediately updates the cache.

void updateUserProfile(UserProfile profile) {
        database.update(profile);
        cache.set(profile.id(), profile, ttl);
    }

This works well when the cache is a shared distributed cache such as Redis because all application servers read from the same cache.

However, many systems introduce a second cache layer inside each application server:

App Server Local Memory Cache (L1)

            ↓

    Redis Distributed Cache (L2)

            ↓

    Database

Local caches are extremely fast because they avoid a network call to Redis, but they introduce a new challenge: stale data.

Imagine Server A updates a user profile:

Server A:
        database.update(...)
        redis.set(...)

    Server B:
        still has old value in local memory

Now Server B may continue serving stale data until its local cache is refreshed or invalidated.

Common solutions include:

• Short TTLs on local cache entries
• Redis Pub/Sub invalidation messages
• Kafka or event-driven cache invalidation
• Versioned cache keys
• Avoiding local caches for highly dynamic data

Once a system grows beyond a single application server, cache consistency becomes more challenging.

Suppose we have:

Users
  ↓
Load Balancer
  ↓
Server A
Server B
Server C
  ↓
Redis
  ↓
Database

If Server A updates a user profile, how do Servers B and C know their cached copy is now stale?

Several approaches are commonly used.

App Server
     ↓
Redis
     ↓
Database

Local Cache (L1)
       ↓
Redis (L2)
       ↓
Database

User Profile
TTL = 30 seconds

Server A updates profile
          ↓
Publish invalidation event
          ↓
Servers B and C receive event
          ↓
Evict local cache entry

Suppose a system records lots of events, counters, or activity logs. Writing synchronously to the database on every change may be too expensive.

A write-behind strategy writes to cache first and persists to the database asynchronously later.

recordEvent(event) {
    cache.increment(event.counterKey());

    // async worker later flushes updates to database
}

Suppose users upload large reports or rarely accessed documents. Writing every new object into cache may waste memory.

A write-around strategy writes directly to the database and does not immediately populate the cache.

void saveReport(Report report) {
    database.save(report);

    // do not cache immediately
    // cache later only if users actually read it
}

Suppose you serve images, JavaScript bundles, CSS files, videos, or public article pages to users around the world.

A CDN cache (Content Delivery Network) stores content at edge locations closer to users. This reduces latency and reduces origin server load.

Suppose you cache comments, activity feeds, leaderboards, or inventory-like data that changes frequently.

One practical approach is TTL-based caching. Every cache key gets an expiration time, and the system accepts that data may be slightly stale for a short period.

cache.set(
    "leaderboard:daily",
    leaderboard,
    Duration.ofSeconds(5)
);

AWS recommends applying TTLs to cache keys in most cases, and notes that short TTLs can be a practical way to protect a hammered database query while evaluating a more elegant solution.

Suppose a homepage, recommendation block, or pricing summary is very expensive to compute and gets requested often.

A refresh-ahead strategy refreshes cached data before it expires, so users are less likely to experience a slow cache miss.

Cache invalidation means removing or refreshing old data when the source of truth changes. Redis describes invalidation as removing old data from the cache so the system can avoid serving outdated data and improve cache usefulness.

Common invalidation approaches include:

• expire keys with TTL
• delete cache keys after database writes
• update cache immediately after writes
• publish events that tell services to evict keys
• version cache keys when data models change

A cache stampede happens when many requests miss the cache at the same time and all hit the database or downstream service together.

Popular key expires
        ↓
1,000 requests miss cache
        ↓
1,000 database queries
        ↓
database spike

Common protections include:

• request coalescing or single-flight loading
• locks around cache rebuilds
• jittered TTLs so many keys do not expire together
• refresh-ahead for very hot keys
• serving stale data briefly while refreshing in the background