Cache‑aside

Backend Fundamentals · Caching · 8 min read

1. What problem does this solve?

Cache‑aside (also called lazy loading) lets an application decide when to read from or write to a cache. It keeps the cache in sync with the source of truth (the DB) while avoiding unnecessary DB traffic. It is a core pattern in microservice architectures, API gateways, and data‑access layers.

2. Mental model

Analogy: The Library & Your Personal Copy

Imagine you’re a researcher who frequently needs a specific paper.

• Without a cache: Every time you need the paper you go to the library, wait in line, and pull it out.
• With cache‑aside: The first time you fetch the paper you copy it into your own notebook (the cache). Subsequent requests read from your notebook, which is instant. If the paper gets updated in the library, you delete the old copy and fetch a fresh one.

Key take‑away: The application owns the cache logic – it decides when to look there, when to fetch from the DB, and when to refresh the cache.

3. Deep explanation

Internals

1. Cache store – usually an in‑memory key/value store (Redis, Memcached).
2. Key design – deterministic, namespaced keys (user:123, product:456).
3. TTL (time‑to‑live) – optional expiration to avoid stale data.
4. Eviction policy – LRU, LFU, FIFO, etc., to keep memory bounded.
5. Serialization – JSON, MessagePack, or binary formats for efficient storage.

Important terminology

Trade‑offs

Failure modes

Limitations

• Write‑heavy workloads: Cache‑aside is not ideal because every write requires cache invalidation.
• Small, infrequently read data: The overhead of cache logic may outweigh benefits.
• Highly dynamic data: Frequent changes make TTL ineffective; cache may become stale quickly.

Where it fits

• Data‑access layer: Service methods that fetch data from DB.
• API gateway: Caching responses to reduce backend load.
• Microservices: Shared cache for common entities (users, products).
• Event‑driven systems: Invalidate cache on domain events (e.g., UserUpdated).

Interaction with related concepts

4. How it works

Step‑by‑step flow

1. Client request arrives at the service.
2. Cache lookup: Service queries Redis for the key.
3. Cache hit → return cached data.
4. Cache miss → query the DB.
5. Store in cache: Save the DB result with an appropriate TTL.
6. Return to client.
7. On write: Update DB, then invalidate or update the cache entry.

sequenceDiagram
    participant Client
    participant App
    participant Cache
    participant DB

    Client->>App: GET /user/42
    App->>Cache: GET user:42
    Cache-->>App: MISS
    App->>DB: SELECT * FROM users WHERE id=42
    DB-->>App: user data
    App->>Cache: SET user:42 data TTL=300
    App-->>Client: user data

    Client->>App: PUT /user/42
    App->>DB: UPDATE users SET ... WHERE id=42
    DB-->>App: OK
    App->>Cache: DEL user:42
    App-->>Client: OK

5. Practical implementation

Below is a minimal, runnable Node.js example using TypeScript and node‑redis.
It demonstrates:

• getUserById (cache‑aside read)
• updateUser (write + cache invalidation)

// src/cache.ts
import { createClient } from 'redis';

export const redis = createClient({
  url: process.env.REDIS_URL ?? 'redis://localhost:6379',
});

redis.on('error', err => console.error('Redis error', err));
await redis.connect();

// src/db.ts
import { Pool } from 'pg';
export const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
});

// src/userService.ts
import { redis } from './cache';
import { pool } from './db';
import { User } from './types';

const USER_KEY = (id: number) => `user:${id}`;
const USER_TTL = 300; // seconds

export async function getUserById(id: number): Promise<User | null> {
  // 1️⃣ Try cache
  const cached = await redis.get(USER_KEY(id));
  if (cached) {
    console.log('Cache hit');
    return JSON.parse(cached) as User;
  }

  // 2️⃣ Miss → DB
  console.log('Cache miss');
  const res = await pool.query('SELECT id, name, email FROM users WHERE id = $1', [id]);
  if (res.rows.length === 0) return null;
  const user = res.rows[0] as User;

  // 3️⃣ Store in cache
  await redis.set(USER_KEY(id), JSON.stringify(user), {
    EX: USER_TTL,
  });

  return user;
}

export async function updateUser(id: number, data: Partial<User>): Promise<void> {
  // 1️⃣ Update DB
  const setClauses = Object.keys(data).map((k, i) => `${k} = ${i + 1}`).join(', ');
  const values = Object.values(data);
  values.push(id);
  await pool.query(`UPDATE users SET ${setClauses} WHERE id = ${values.length}`, values);

  // 2️⃣ Invalidate cache
  await redis.del(USER_KEY(id));
}

Key points

• USER_KEY ensures deterministic namespacing.
• EX sets TTL; adjust based on data volatility.
• Invalidation (DEL) guarantees that subsequent reads hit the DB until the next cache fill.

6. Production considerations

7. Common mistakes

8. Senior engineer perspective

What changes at scale?

• Cache partitioning: Use Redis Cluster or multiple shards to avoid a single point of contention.
• Eviction strategy: LRU may not be optimal for all workloads; consider LFU or custom policies.
• Key design: Include tenant ID, environment, or version to avoid cross‑tenant leaks.
• Consistency model: Decide between eventual consistency (cache‑aside) vs. strong consistency (write‑through).
• Monitoring: Set up dashboards for hit/miss ratio, latency, eviction count, and memory usage.
• Cost: Memory is expensive; balance TTL and eviction to keep cache size reasonable.
• Failure scenarios: Plan for network partitions, Redis node failures, and data center outages.
• Testing: Use chaos engineering to simulate cache failures and ensure graceful degradation.
• When NOT to use: If writes dominate reads, or data changes every request, a cache may add more complexity than benefit.

9. Interview questions

10. Hands‑on task

Goal: Build a small Node.js service that exposes two endpoints:

1. GET /product/:id – uses cache‑aside to fetch product details from PostgreSQL and cache in Redis.
2. PUT /product/:id – updates the product in PostgreSQL and invalidates the cache.

Steps

1. Setup Docker Compose

   version: '3.8'
   services:
     postgres:
       image: postgres:15
       environment:
         POSTGRES_USER: user
         POSTGRES_PASSWORD: pass
         POSTGRES_DB: shop
       ports: ["5432:5432"]
     redis:
       image: redis:7
       ports: ["6379:6379"]
     app:
       build: .
       environment:
         DATABASE_URL: postgres://user:pass@postgres:5432/shop
         REDIS_URL: redis://redis:6379
       ports: ["3000:3000"]
   

2. Create a simple schema (products table with id, name, price).
3. Implement the service using the code pattern from section 5.
4. Run docker compose up and test with curl or Postman.
5. Observe cache behavior:
   • First request → cache miss, DB hit.
   • Subsequent request → cache hit.
   • After PUT, cache is invalidated; next GET triggers a miss again.

Deliverable: A GitHub repo with Dockerfile, docker-compose.yml, TypeScript source, and a README explaining how to run and test.

11. Quick revision

• Cache‑aside: application‑controlled cache read/write.
• Cache hit → fast, no DB.
• Cache miss → fetch from DB, store in cache, return.
• Write path: update DB → invalidate or update cache.
• Key design: deterministic, namespaced, tenant‑aware.
• TTL: controls staleness; balance with eviction policy.
• Cache stampede: mitigate with locks or token bucket.
• Observability: monitor hit/miss ratio, latency, evictions.
• Failure handling: graceful degradation, circuit breaker.
• Scaling: use Redis Cluster, consistent hashing, sharding.
• When not to use: write‑heavy workloads, data that changes every request.

12. References

• Redis Documentation – Key Concepts
• node‑redis v4 Docs
• PostgreSQL Official Docs
• Prometheus Redis Exporter
• Cache‑Aside Pattern – Martin Fowler
• Cache Stampede Prevention – AWS Whitepaper