کش توزیع‌شده Redis در Next.js: از ISR تا stale-while-revalidate

«کش را کجا بزنیم؟» — در اپلیکیشن‌های Next.js جواب واحدی ندارد، چون سه لایه با سه هزینه باطل‌سازی داریم. در این مقاله مرز هر لایه و تله رایجِ جا‌به‌جایی آن‌ها را روشن می‌کنیم.

سه لایه، سه سؤال

• لایه ۱ — کش رندر (unstable_cache / نتیجه توابع): برای داده خواندنیِ پرتکرار داخل رندر. تگ باطل‌سازی دارد.
• لایه ۲ — ISR / revalidate: کل HTML صفحه، به‌ازای بازه زمانی. ارزان‌ترین راه برای صفحات کاتالوگی.
• لایه ۳ — داده Redis: وقتی چند سرویس (API جدا، worker، لبه) باید همان داده را ببینند.

import { unstable_cache } from "next/cache";
import { CACHE_TAGS } from "@/lib/cache";
import { redis } from "@/server/redis";

// لایه ۱: تابع خواندن با تگ — نتیجه بین requestها مشترک است
export const getPlans = unstable_cache(
  async () => prisma.pricingTier.findMany({ orderBy: { order: "asc" } }),
  ["pricing-plans"],
  { tags: [CACHE_TAGS.pricing], revalidate: 3600 },
);

// لایه ۳: داده بین سرویسی با TTL کوتاه
export async function getStock(sku: string) {
  const key = `stock:${sku}`;
  const hit = await redis.get(key);
  if (hit) return JSON.parse(hit) as number;
  const value = await readStock(sku);
  await redis.set(key, String(value), { EX: 30 });
  return value;
}

تله باطل‌سازی رایج

ttl را «برای اطمینان» بلند می‌کنند و بعد از تغییر داده، محتوای کهنه ساعت‌ها زنده می‌ماند. قاعده ما: هر mutation باید صریحاً تگ‌های مرتبط را با revalidateTag باطل کند — نه اینکه روی انقضا حساب کند.

اگر بعد از publish، مقاله قدیمی را می‌بینید، مشکل TTL نیست؛ مشکل نبودن یک خط revalidateTag است.

کجا لایه را حذف کنیم

یک جدول ساده برای تصمیم:

نوع داده	لایه مناسب
تنظیمات سایت (تغییر نادر)	unstable_cache + tag
صفحات کاتالوگی پرمراجعه	ISR با revalidate مناسب
شمارنده/موجودی زنده	Redis با TTL کوتاه
داده per-user	کش نکنید (یا فقط در session)

نتیجه‌گیری

کشینگ درست یعنی برای هر لایه یک «سوال» مشخص داشته باشید: این داده چند بار خوانده می‌شود، چه کسی آن را عوض می‌کند، و چند ثانیه کهنه بودنش قابل قبول است. جواب این سه پرسش، لایه را انتخاب می‌کند — نه عادت.