Cache-Aside (Lazy Loading)

Cache-aside is the pattern most teams mean when they say “we added caching.” The application looks in the cache first, loads from the authoritative source on miss, and then stores the result in the cache for later reuse. The cache is therefore optional in the control flow, while the application owns the logic that fills and invalidates it.

This pattern is popular because it is simple to layer into existing code. It also keeps the source of truth explicit. But it pushes correctness into application logic. Every code path that reads or writes relevant data now has to think about cache population, invalidation, or refresh.

    sequenceDiagram
	    participant App
	    participant Cache
	    participant Store
	
	    App->>Cache: get(key)
	    alt hit
	        Cache-->>App: cached value
	    else miss
	        Cache-->>App: miss
	        App->>Store: load authoritative value
	        Store-->>App: value
	        App->>Cache: set(key, value, ttl)
	    end

Why It Matters

Cache-aside is attractive precisely because it is explicit. You can see the source lookup, the cache write, and the fallback path in the same code. That clarity makes it a good default for many systems. The cost is that stampede prevention, key consistency, invalidation discipline, and fallback behavior become application concerns rather than infrastructure concerns.

Why Teams Start Here

This pattern works well when:

• the application already owns the data access path
• the team wants clear control over miss handling
• cache unavailability should not prevent reads from reaching the source of truth
• the system can tolerate eventual cache population rather than eager warming

It is often the least surprising option when introducing a new cache incrementally.

Example

This TypeScript example shows a typical cache-aside read path with explicit miss handling.

 1async function getUserProfile(userId: string): Promise<UserProfile> {
 2  const key = `user-profile:${userId}`;
 3  const cached = await cache.get(key);
 4
 5  if (cached) {
 6    return JSON.parse(cached) as UserProfile;
 7  }
 8
 9  const profile = await profileStore.fetch(userId);
10  await cache.set(key, JSON.stringify(profile), 120);
11  return profile;
12}
13
14async function updateUserProfile(userId: string, patch: Partial<UserProfile>): Promise<void> {
15  await profileStore.update(userId, patch);
16  await cache.delete(`user-profile:${userId}`);
17}

What to notice:

• the application owns both population and invalidation
• reads can still succeed if the cache is empty
• stale data risk moves into the write path because invalidation must happen consistently

Common Failure Modes

The two most common cache-aside problems are:

• missed invalidation after writes
• miss storms when many callers request the same hot key at once

The second issue is especially common when a hot key expires and many concurrent requests all rebuild it independently. That is why cache-aside is often paired with singleflight, lock-based fill, or stale-while-revalidate techniques later in the guide.

Common Mistakes

• forgetting to invalidate or refresh after writes
• duplicating key logic across code paths inconsistently
• assuming a cache miss is harmless even when many misses can synchronize
• caching results that are too user-specific without modeling scope carefully

Design Review Question

What makes cache-aside a strong default pattern for many teams despite its invalidation burden?

The stronger answer is that it keeps the source of truth and miss behavior explicit in application code. That makes the system easier to introduce incrementally and easier to degrade safely when the cache is empty or unavailable, even though it puts more discipline burden on the application.

Quiz Time