امروز یک قابلیت جدید به‌نام Cache Response Rules معرفی شده است که دقیقاً پس از بازگشت پاسخ از origin و قبل از اینکه محتوا در لبه (edge) کش شود اجرا می‌شود. این قابلیت برای زمانی مفید است که یک هدر مزاحم مثل Set-Cookie یا Cache-Control اشتباه باعث می‌شود منابعی که باید از کش سرو شوند، دوباره به origin برگردند — مشکلی که گاهی تغییر آن در خودِ origin سخت یا غیرممکن است. 🚀

معمولاً یک CDN و origin مثل دو همکار عمل می‌کنند: هدف این است که هرچه بیشتر از کش پاسخ دهیم و تنها وقتی به origin مراجعه کنیم که edge نتواند جواب دهد. نسبت موفقیت در کش (cache hit ratio) وقتی بالا می‌رود که تقسیم وظایف بین edge و origin درست انجام شود؛ اگر بیش‌ازحد به origin مراجعه کنیم، مزیت عملکرد و هزینه‌ای که انتظار داریم از بین می‌رود.

نکتهٔ کلیدی این است که origin تعیین می‌کند چه چیزی کش شود: هدرهای پاسخ origin مشخص می‌کنند که یک دارایی چه مدت قابل سرو است، چگونه باید revalidate شود یا اصلاً آیا قابل کش است یا خیر. اگر origin اشتباه پیکربندی شود، کش عملاً بی‌اثر می‌شود و بار روی زیرساخت origin بالا می‌رود.

بیشتر مشکلات مربوط به اهلگی کش (cache eligibility) بعد از پاسخ origin خودش را نشان می‌دهد، نه هنگام دریافت درخواست. مثلاً یک کاربر درخواست /static/app.js می‌کند، edge کش را بررسی می‌کند، miss می‌خورد و درخواست را به origin می‌فرستد. origin فایل را برمی‌گرداند اما همراه آن هدرهایی مثل Set-Cookie یا Cache-Control: private هست که باعث می‌شود edge آن را کش نکند و دفعه بعد دوباره به origin بازگردد — در حالی که آن دارایی کاملاً cacheable بوده است.

Cache Response Rules دقیقاً در همین لحظه بین origin و کش وارد عمل می‌شود: شما می‌توانید هدرهای پاسخ را اصلاح یا حذف کنید، TTL را روی edge بازنویسی کنید، یا قواعد دیگری اعمال کنید تا پاسخ‌ها قابل کش شوند یا رفتار کش مطابق نیاز شما تنظیم شود. این تغییرات در لبه اعمال می‌شوند و نیازی به تغییر در origin نیست — چیزی که برای محیط‌های production یا سرویس‌های third-party بسیار ارزشمند است. 🛠️

نمونهٔ اقداماتی که با این رول‌ها می‌توانید انجام دهید: حذف یا تغییر Set-Cookie، بازنویسی Cache-Control، اضافه کردن stale-while-revalidate، تعیین Edge TTL، یا اعمال شرط‌های دقیق بر اساس مسیر، هدرهای درخواست، status code، یا مقدار کوکی‌ها. البته همیشه باید مراقب باشید تا محتوای شخصی‌سازی‌شده یا حساس را به‌اشتباه کش نکنید.

چند توصیه عملی برای تیم‌های DevOps / SRE:

– در محیط تست (staging) قواعد را آزمایش کنید و رفتار cache hit ratio و latency را پایش کنید.
– از شروط دقیق استفاده کنید تا فقط منابع ایمن و عمومی کش شوند (مثلاً مسیرهای static یا پاسخ‌هایی با status 200 و بدون هدرهای مشخصِ حساس).
– متریک‌ها و لاگ‌های کش را برای بررسی تأثیر تغییرات زیر نظر بگیرید؛ دنبال افزایش cache hit ratio و کاهش درخواست‌های origin باشید.
– مراقب Vary، Authorization و هر هدر دیگری که ممکن است محتوای user-specific ایجاد کند باشید؛ اگر مطمئن نیستید، بهتر است قاعده محدودتری بنویسید.

در مجموع، Cache Response Rules ابزاری قدرتمند برای کنترل رفتار کش در لبه است و مخصوصاً برای تیم‌هایی که نمی‌توانند به راحتی origin را تغییر دهند یا می‌خواهند با حداقل تغییرات، هزینه و تاخیر را کاهش دهند مفید خواهد بود. امتحانش کنید و تاثیرش را روی cache hit ratio و بار origin بسنجید — معمولاً نتیجه محسوس است. 💡