read_heavy_hotspot signal — @periodic/arsenic

read_heavy_hotspot

⚠️ Warning

High-frequency reads on specific records

Concentrated read activity on specific data points — a prime caching opportunity. The same records are fetched repeatedly, potentially overwhelming database replicas.

Common Causes

—Popular content without caching
—Configuration or settings fetched per request
—User profile data fetched on every authenticated request
—Product catalog without CDN or cache

How to Fix

1.Implement Redis caching with TTL
2.Add read replicas for hot data
3.Use CDN for static/semi-static data
4.Denormalize hot data

Example

typescript

// GOOD — cache hot records with TTL
async function getUser(id: string) {
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);

  const user = await User.findById(id).lean();
  await redis.setex(`user:${id}`, 300, JSON.stringify(user));
  return user;
}

Cache invalidation strategy matters

A TTL cache is simple but stale. Use event-driven invalidation (redis.del on write) for data that must be fresh.

Cache-aside with invalidation

typescript

const CACHE_TTL = 300; // 5 minutes

async function getProduct(id: string) {
  const cached = await redis.get(`product:${id}`);
  if (cached) return JSON.parse(cached);

  const product = await prisma.product.findUnique({ where: { id } });
  await redis.setex(`product:${id}`, CACHE_TTL, JSON.stringify(product));
  return product;
}

// Invalidate on write — keep cache consistent
async function updateProduct(id: string, data: Partial<Product>) {
  const updated = await prisma.product.update({ where: { id }, data });
  await redis.del(`product:${id}`); // bust cache immediately
  return updated;
}