Redis cache-aside for expensive reads

8878 views

                  import { createClient } from 'redis';

export const redis = createClient({ url: process.env.REDIS_URL });

export async function cacheAside<T>(key: string, ttlSeconds: number, loader: () => Promise<T>): Promise<T> {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached) as T;

  const value = await loader();
  const jitter = Math.floor(Math.random() * Math.min(10, ttlSeconds / 10));
  await redis.set(key, JSON.stringify(value), { EX: ttlSeconds + jitter });
  return value;
}

Most ‘caching’ bugs are really invalidation bugs, so I stick to a simple cache-aside pattern with conservative TTLs and treat cache misses as normal. The big failure mode to avoid is a stampede: if many requests miss at once, you can crush your DB. For most endpoints, a short TTL plus jitter is enough, and I keep cache keys explicit + versioned so I can roll forward without flushing Redis on deploy. When the response shape changes, bump the version prefix and the new code naturally warms fresh keys. I also prefer to cache serialized payloads (like JSON strings) so the cache value is transportable and debugging is straightforward.

Mateo Rodriguez

More from Mateo Rodriguez

Redis cache-aside for expensive reads

0 Comments

More from Mateo Rodriguez