Cache Strategies

The Four Strategies

Every caching system is built on one of four patterns — or a combination. The choice determines who owns cache population, how stale data appears, and what happens on writes.

Strategy	Who reads from DB	Who writes to DB	Consistency
Cache-aside	Application	Application	Eventual
Read-through	Cache layer	Application	Eventual
Write-through	Application	Cache layer → DB	Strong
Write-behind	Application	Cache layer (async)	Eventual

Cache-Aside (Lazy Loading)

The most common pattern. The application owns all the logic: check cache, miss → fetch from DB, populate cache.

class UserService {
	constructor(
		private cache: RedisClient,
		private db: Database
	) {}

	async getUser(id: string): Promise<User> {
		const cacheKey = `user:${id}`;

		// 1. Try cache
		const cached = await this.cache.get(cacheKey);
		if (cached) return JSON.parse(cached);

		// 2. Cache miss — fetch from DB
		const user = await this.db.users.findById(id);
		if (!user) throw new NotFoundError(`User ${id} not found`);

		// 3. Populate cache (TTL: 5 minutes)
		await this.cache.setex(cacheKey, 300, JSON.stringify(user));

		return user;
	}

	async updateUser(id: string, data: Partial<User>): Promise<User> {
		const user = await this.db.users.update(id, data);

		// Invalidate — don't update cache, let next read repopulate
		await this.cache.del(`user:${id}`);

		return user;
	}
}

Pros: Simple. Only caches what’s actually requested. Cache survives Redis restarts (just repopulates from DB on next request).

Cons: First request after a miss is slow. Can serve stale data if you forget to invalidate on write.

Read-Through

The cache layer itself fetches from the database on a miss, transparently to the application. The application only talks to the cache.

// The cache wraps the data source
class ReadThroughCache<T> {
	private store = new Map<string, { value: T; expiresAt: number }>();

	constructor(private loader: (key: string) => Promise<T>) {}

	async get(key: string): Promise<T> {
		const entry = this.store.get(key);
		if (entry && Date.now() < entry.expiresAt) {
			return entry.value; // hit
		}

		// miss — load through
		const value = await this.loader(key);
		this.store.set(key, { value, expiresAt: Date.now() + 300_000 });
		return value;
	}
}

// Application just calls get — doesn't know about DB
const userCache = new ReadThroughCache<User>((id) => db.users.findById(id));

const user = await userCache.get('user:123');

Pros: Simpler application code — one place handles all cache population logic.

Cons: Cold start still has latency. Harder to handle cache misses differently (e.g., returning null vs throwing). Libraries like node-cache-manager implement this pattern.

Write-Through

Every write goes through the cache to the database. Cache and DB are always in sync.

class WriteThroughUserCache {
	async saveUser(user: User): Promise<void> {
		// Write to DB and cache atomically
		await Promise.all([
			this.db.users.upsert(user),
			this.cache.setex(`user:${user.id}`, 3600, JSON.stringify(user))
		]);
	}

	async getUser(id: string): Promise<User | null> {
		const cached = await this.cache.get(`user:${id}`);
		if (cached) return JSON.parse(cached);

		// Only miss on first access or after eviction
		const user = await this.db.users.findById(id);
		if (user) {
			await this.cache.setex(`user:${id}`, 3600, JSON.stringify(user));
		}
		return user;
	}
}

Pros: Cache is always fresh — no stale reads. No invalidation logic needed.

Cons: Write latency increases (two writes). Cache fills with data that may never be read. Works best with read-through to handle initial loads.

Write-Behind (Write-Back)

Writes go to cache immediately, then the cache asynchronously flushes to the database. The application gets fast write acknowledgment.

class WriteBehindCache {
	private dirtyKeys = new Set<string>();
	private flushInterval: NodeJS.Timeout;

	constructor(
		private cache: Map<string, unknown>,
		private db: Database,
		flushEveryMs = 1000
	) {
		// Flush dirty keys to DB every second
		this.flushInterval = setInterval(() => this.flush(), flushEveryMs);
	}

	async write(key: string, value: unknown): Promise<void> {
		this.cache.set(key, value); // immediate, synchronous
		this.dirtyKeys.add(key); // mark for async flush
		// Returns immediately — DB write happens later
	}

	private async flush(): Promise<void> {
		const keys = [...this.dirtyKeys];
		this.dirtyKeys.clear();

		await Promise.all(
			keys.map(async (key) => {
				const value = this.cache.get(key);
				if (value !== undefined) {
					await this.db.set(key, value);
				}
			})
		);
	}

	destroy(): void {
		clearInterval(this.flushInterval);
	}
}

Pros: Lowest write latency. Can batch multiple writes into one DB operation. Great for counters, view counts, analytics.

Cons: Data loss risk if cache crashes before flushing. Complex failure handling. Not appropriate for financial or critical data.

Refresh-Ahead

Proactively refresh cache before entries expire, based on access patterns.

class RefreshAheadCache<T> {
	private store = new Map<
		string,
		{
			value: T;
			expiresAt: number;
			refreshAt: number; // refresh when this passes, before expiry
		}
	>();

	constructor(
		private loader: (key: string) => Promise<T>,
		private ttlMs: number,
		private refreshThreshold = 0.8 // refresh when 80% of TTL has passed
	) {}

	async get(key: string): Promise<T | null> {
		const entry = this.store.get(key);

		if (!entry) return null; // cold miss

		const now = Date.now();

		// Trigger background refresh if nearing expiry
		if (now > entry.refreshAt && now < entry.expiresAt) {
			this.refreshInBackground(key); // don't await
		}

		if (now > entry.expiresAt) return null; // expired

		return entry.value;
	}

	private async refreshInBackground(key: string): Promise<void> {
		const value = await this.loader(key);
		const now = Date.now();
		this.store.set(key, {
			value,
			expiresAt: now + this.ttlMs,
			refreshAt: now + this.ttlMs * this.refreshThreshold
		});
	}
}

Pros: Eliminates most cache misses. Popular keys are never cold.

Cons: Wastes work refreshing keys that won’t be read again. Complex to implement correctly. Overkill for most applications.

Choosing a Strategy

Start here:
  Is your read:write ratio > 10:1?
    Yes → Cache-aside. Simple, effective.
    No  → Is write latency critical?
            Yes → Write-behind (accept data loss risk)
            No  → Write-through (if consistency matters)

Do you need zero stale reads?
  Yes → Write-through + short TTL
  No  → Cache-aside with reasonable TTL

Multiple services sharing the same data?
  Yes → Distributed cache (Redis) + cache-aside
  No  → In-process cache, don't bother with Redis

Key Design Rules

Always expire entries. A cache with no TTL is a memory leak with extra steps. Even a 24-hour TTL is better than never expiring.

Make cache keys deterministic. user:${id} not user_${Date.now()}. If the same inputs don’t produce the same key, you’ll never hit.

Namespace your keys. Prefix by service or entity type: auth:session:abc123, catalog:product:456. Prevents collisions when sharing Redis across services.

Serialize consistently. JSON.stringify produces different output depending on key order in some environments. Use a canonical serializer or be aware of this.

// Good: deterministic key
const key = `product:${productId}:v2`;

// Bad: non-deterministic
const key = `product:${productId}:${Date.now()}`;

// Good: namespaced
const key = `catalog:product:${productId}`;

// Canonical JSON for complex keys
import { stringify } from 'fast-json-stable-stringify';
const key = `search:${stringify({ query, page, filters })}`;