Redis Caching Strategies: Cache-Aside, Read-Through, Write-Behind, and When Each One Actually Makes Sense

Your product page loads in 200ms on the first request. On the second request, with a warm cache, it takes 12ms. You add a write-through cache so every database write also updates Redis. Now the product page is always fast, but your checkout endpoint dropped from 80ms to 400ms because every inventory decrement now waits for two round trips to Redis.

The strategy that made the read path fast made the write path slow. Trade-offs like this are the norm, not the exception, and most teams discover them in production after the pager goes off.

Here is the map of the four Redis caching strategies, the exact code for each, and the workload profile that earns each one.

The four strategies in one table

Strategy	Reads from	Writes to	Stale data risk	Write latency	Complexity
Cache-Aside	Cache, then DB	DB only (cache invalidated)	Low	None added	Low
Read-Through	Cache (cache loads from DB)	DB only	Low	None added	Medium
Write-Through	Cache, then DB	Cache + DB (synchronous)	None	Added	Medium
Write-Behind	Cache, then DB	Cache only (async DB flush)	High	None added	High

Every strategy is correct for some workload and wrong for others. The mistake is picking one and using it everywhere.

Strategy 1: Cache-Aside (the default that works)

Cache-aside is the simplest and most common pattern. The application checks the cache first. On a miss, it loads from the database, writes to the cache, and returns the data. On a write, it updates the database and invalidates (or updates) the cache.

import { createClient } from 'redis';
import { db } from './db';

const cache = createClient({ url: process.env.REDIS_URL });
await cache.connect();

async function getUser(id: string) {
  const cacheKey = `user:${id}`;

  // Check cache first
  const cached = await cache.get(cacheKey);
  if (cached) {
    return JSON.parse(cached);
  }

  // Cache miss -- load from database
  const user = await db.query('SELECT * FROM users WHERE id = $1', [id]);

  if (!user) return null;

  // Populate cache with a TTL
  await cache.setEx(cacheKey, 300, JSON.stringify(user));
  return user;
}

async function updateUser(id: string, data: Partial<User>) {
  // Update database first
  const user = await db.query(
    'UPDATE users SET name = $1, updated_at = NOW() WHERE id = $2 RETURNING *',
    [data.name, id]
  );

  // Invalidate cache -- next read will re-populate
  await cache.del(`user:${id}`);

  return user;
}

The invalidation step is what makes cache-aside work. Some teams update the cache instead of invalidating it, which saves one cache miss at the cost of a race condition: another request could read the stale cache value between your database write and your cache update. Deleting the key and letting the next read populate it is simpler and safer.

When to use it: Almost everything. Read-heavy workloads, user profiles, product details, settings. It is the default for a reason.

When to avoid it: When a cache miss triggers an expensive database query and thousands of concurrent requests can hit the same miss at once. That is the thundering-herd problem, and cache-aside does not solve it without help.

Fixing the thundering herd with locking

When a hot key expires and 500 requests all miss the cache at once, they all hit the database. The fix is to let only one request populate the cache and have the rest wait:

async function getUserWithLock(id: string) {
  const cacheKey = `user:${id}`;
  const lockKey = `lock:user:${id}`;

  const cached = await cache.get(cacheKey);
  if (cached) return JSON.parse(cached);

  // Try to acquire a short-lived lock
  const lockAcquired = await cache.setnx(lockKey, '1', { EX: 2 });
  if (!lockAcquired) {
    // Another request is loading -- wait briefly and retry
    await new Promise(r => setTimeout(r, 50));
    const retry = await cache.get(cacheKey);
    if (retry) return JSON.parse(retry);
    // Lock holder failed -- fall through
  }

  try {
    const user = await db.query('SELECT * FROM users WHERE id = $1', [id]);
    if (user) {
      await cache.setEx(cacheKey, 300, JSON.stringify(user));
    }
    return user;
  } finally {
    await cache.del(lockKey);
  }
}

The lock TTL is set to 2 seconds, which is longer than any reasonable database query. If the lock holder crashes, the lock expires automatically and the next request retries. This is not distributed-lock-grade coordination (that would be Redlock), but for preventing a stampede on a single cache key it is good enough.

Strategy 2: Read-Through (the cache loads itself)

Read-through moves the cache-population logic into the cache layer itself. You configure Redis with a user-defined function or use a client-side loader pattern. In practice, most Node.js teams implement read-through as a thin abstraction over cache-aside:

type Loader<T> = (key: string) => Promise<T | null>;

function createReadThroughCache<T>(opts: {
  prefix: string;
  ttl: number;
  loader: Loader<T>;
}) {
  return {
    async get(key: string): Promise<T | null> {
      const cacheKey = `${opts.prefix}:${key}`;

      const cached = await cache.get(cacheKey);
      if (cached) return JSON.parse(cached);

      // The cache calls the loader function
      const value = await opts.loader(key);
      if (value !== null) {
        await cache.setEx(cacheKey, opts.ttl, JSON.stringify(value));
      }
      return value;
    },

    // After a write, the application tells the cache to refresh
    async invalidate(key: string) {
      await cache.del(`${opts.prefix}:${key}`);
    }
  };
}

// Usage
const userCache = createReadThroughCache<User>({
  prefix: 'user',
  ttl: 300,
  loader: async (id) => {
    const result = await db.query('SELECT * FROM users WHERE id = $1', [id]);
    return result || null;
  }
});

// Read
const user = await userCache.get('abc-123');

// Write
await db.query('UPDATE users SET name = $1 WHERE id = $2', ['Alice', 'abc-123']);
await userCache.invalidate('abc-123');

The advantage over raw cache-aside is that the loader function is colocated with the cache configuration. Every developer on the team knows to call userCache.get(), not cache.get() plus a manual database query. The disadvantage is that invalidation must still happen manually after writes — a step that is easy to forget.

When to use it: Any codebase with multiple consumers of the same cached data. A read-through cache provides a single source of truth for how data is loaded and cached.

When to avoid it: When the loader function has side effects or reads from multiple sources. Read-through assumes one key maps to one database query, which is not always true.

Strategy 3: Write-Through (always consistent, always slower)

Write-through updates the cache and the database in the same synchronous operation. Every write goes to Redis first (or simultaneously), and the application waits for both to succeed before responding.

async function updateUserWriteThrough(id: string, data: Partial<User>) {
  const cacheKey = `user:${id}`;

  // Use Redis MULTI/EXEC to validate the cache key exists
  // then update both stores
  const [dbResult] = await Promise.all([
    db.query(
      'UPDATE users SET name = $1, updated_at = NOW() WHERE id = $2 RETURNING *',
      [data.name, id]
    ),
    cache.setEx(cacheKey, 300, JSON.stringify({ ...data, id }))
  ]);

  return dbResult.rows[0];
}

The Promise.all fires both updates concurrently, so the write latency is the max of the two operations, not the sum. Even so, you added a network round trip to Redis on every write. For a service that serves 80% reads and 20% writes, this is a fine trade-off. For a service that handles 50,000 writes per second, it is not.

The real risk with write-through is partial failure. What if the database write succeeds but the cache write fails? Now the cache has stale data even though you tried to keep it current. The safest recovery is to treat a failed cache write as an invalidation:

async function updateUserSafe(id: string, data: Partial<User>) {
  const cacheKey = `user:${id}`;

  const dbPromise = db.query(
    'UPDATE users SET name = $1, updated_at = NOW() WHERE id = $2 RETURNING *',
    [data.name, id]
  );

  const cachePromise = cache.setEx(cacheKey, 300, JSON.stringify({ ...data, id }))
    .catch(() => cache.del(cacheKey)); // Invalidate on failure

  const [result] = await Promise.all([dbPromise, cachePromise]);
  return result.rows[0];
}

When to use it: When read-after-write consistency is a hard requirement. Payment status, inventory counts, seat availability — any data where serving a stale value is worse than serving nothing.

When to avoid it: When your write volume exceeds what your Redis cluster can handle or when your data model has frequent batch updates. Write-through on every row update in a batch import will multiply your write latency by a factor of 2-3x.

Strategy 4: Write-Behind (fast writes, eventual consistency)

Write-behind acknowledges the write immediately (cache is updated) and asynchronously flushes it to the database. This is the fastest write path of any strategy, but it introduces a window where a crash loses data.

import { createClient } from 'redis';

const WRITE_QUEUE_KEY = 'write-behind:queue';
const FLUSH_INTERVAL_MS = 1000;
const MAX_BATCH_SIZE = 100;

async function flushQueue() {
  while (true) {
    // Atomically read and remove a batch from the Redis list
    const batch = await cache.lPopCount(WRITE_QUEUE_KEY, MAX_BATCH_SIZE);
    if (batch.length === 0) {
      await new Promise(r => setTimeout(r, FLUSH_INTERVAL_MS));
      continue;
    }

    const operations = batch.map(item => JSON.parse(item));

    // Batch write to the database
    const client = await dbPool.connect();
    try {
      await client.query('BEGIN');
      for (const op of operations) {
        await client.query(
          'UPDATE users SET name = $1, updated_at = NOW() WHERE id = $2',
          [op.data.name, op.id]
        );
      }
      await client.query('COMMIT');
    } catch (err) {
      await client.query('ROLLBACK');
      // Re-queue failed operations with a retry count
      for (const item of batch) {
        const op = JSON.parse(item);
        if ((op.retries || 0) < 3) {
          op.retries = (op.retries || 0) + 1;
          await cache.rPush(WRITE_QUEUE_KEY, JSON.stringify(op));
        } else {
          // Dead letter queue
          await cache.rPush('write-behind:dead-letter', item);
          console.error('Write-behind exhausted retries:', op.id);
        }
      }
    } finally {
      client.release();
    }
  }
}

// Start the flush loop
flushQueue().catch(err => console.error('Flush loop crashed:', err));

// Application writes
async function updateUserWriteBehind(id: string, data: Partial<User>) {
  const cacheKey = `user:${id}`;

  // Update cache immediately
  await cache.setEx(cacheKey, 300, JSON.stringify({ ...data, id }));

  // Queue the database write
  await cache.rPush(WRITE_QUEUE_KEY, JSON.stringify({
    id,
    data,
    ts: Date.now()
  }));
}

The producer (your API) only waits for Redis. The consumer (the flush loop) batches database writes every second or every 100 operations, whichever comes first. If Redis or the API crashes before the flush, those updates are lost.

When to use it: High-write-volume workloads where losing a few seconds of data is acceptable. Analytics events, page view counters, user activity logs, any append-heavy reporting data.

When to avoid it: When data loss is unacceptable. Invoice creation, user registration, payment processing — anything that would cause a financial or legal problem if it disappeared. Write-behind is eventual consistency on a timer, and that timer is a data-loss window.

Making write-behind safer with Redis Streams

A Redis List (what the example above uses) works but has no consumer group semantics. If your flush loop restarts, it re-reads the whole queue. Redis Streams with consumer groups solve this:

const STREAM_KEY = 'write-behind:stream';
const GROUP_NAME = 'db-writer';
const CONSUMER_NAME = `writer-${process.pid}`;

async function initStream() {
  try {
    await cache.xGroupCreate(STREAM_KEY, GROUP_NAME, '0', { MKSTREAM: true });
  } catch (err: any) {
    if (!err.message.includes('BUSYGROUP')) throw err;
  }
}

async function enqueueWrite(id: string, data: Partial<User>) {
  await cache.xAdd(STREAM_KEY, '*', {
    id,
    data: JSON.stringify(data),
    ts: String(Date.now())
  });
}

async function processStream() {
  while (true) {
    const results = await cache.xReadGroup(
      GROUP_NAME, CONSUMER_NAME,
      [{ key: STREAM_KEY, id: '>' }],
      { COUNT: 50, BLOCK: 1000 }
    );

    if (!results) continue;

    for (const { messages } of results) {
      for (const { id: messageId, message } of messages) {
        try {
          const payload = {
            id: message.id,
            data: JSON.parse(message.data),
            ts: Number(message.ts)
          };

          await db.query(
            'UPDATE users SET name = $1, updated_at = NOW() WHERE id = $2',
            [payload.data.name, payload.id]
          );

          // Acknowledge the message
          await cache.xAck(STREAM_KEY, GROUP_NAME, messageId);
        } catch (err) {
          console.error('Stream processing failed:', messageId, err);
          // Do not ACK -- it will be retried
        }
      }
    }
  }
}

Streams give you persistent storage (messages survive Redis restarts), consumer groups (only one consumer processes each message), and automatic retries (unacknowledged messages are redelivered to another consumer). This is the production-grade write-behind implementation.

How to pick the right strategy

The decision tree has three questions:

1. Can your reads tolerate stale data?

If yes: cache-aside or read-through. Let the cache serve old data within a TTL window and invalidate on writes.

If no: write-through. Every read after a write sees the current state, at the cost of slower writes.

2. What is your read-to-write ratio?

If reads dominate (10:1 or higher): any strategy works, but cache-aside is the simplest and easiest to debug.

If writes dominate or are near parity: write-behind or cache-aside with TTL-only expiration (no invalidation on writes). Write-through will multiply your write latency.

3. What happens if you lose data in the cache?

If losing cached data means lost revenue or compliance violations: write-through, with cache-write monitoring and alerting.

If losing cached data means a slightly stale dashboard for thirty seconds: cache-aside with a reasonable TTL.

If losing cached data means losing the data itself (the cache is the only source): write-behind with Redis Streams and disk persistence, plus a dead-letter queue and alerting.

The strategy that covers most cases

For most CRUD applications, cache-aside with TTL-based expiration and write-through invalidation on the hot paths is the right default. Read-through adds a nice abstraction layer once you have multiple consumers. Write-behind is a specialist tool for high-volume, loss-tolerant workloads.

The real risk is not picking the wrong strategy. It is picking one strategy, applying it to every data access pattern in your service, and never revisiting the decision. A product catalog with 50,000 reads per second and 5 writes per second should be on a different strategy than a real-time inventory system with equal read and write throughput. They are different workloads. Treat them differently.

Set a calendar reminder six months from now. Revisit your cache strategy. Measure your read-to-write ratio. Check whether your invalidation logic is still correct after the schema changes and refactors your team shipped in those six months. Chances are, the cache works and the invalidation logic has quietly rotted. That is the other common failure mode, and it is the subject of its own post.

---

A note from Yojji

Cache strategy decisions like these are exactly the kind of infrastructure-level design that separates a service that scales predictably from one that falls over under load. Getting the invalidation logic right, picking the right strategy per workload, and building the monitoring that tells you when the cache is helping versus hiding a problem — these are the details that make a production system trustworthy.

That kind of careful, workload-aware backend engineering is what Yojji has been delivering since 2016. Yojji is an international custom software development company with offices in Europe, the US, and the UK. Their teams specialize in the JavaScript ecosystem (React, Node.js, TypeScript), cloud platforms (AWS, Azure, Google Cloud), and microservices architectures, and they run dedicated senior outstaffed teams alongside full-cycle product engagements covering discovery, design, development, QA, and DevOps.

If your team would rather hire engineers who have already made these mistakes and learned from them than discover each one in a production incident, Yojji is worth a conversation.