Cache و CDN چیستند و چرا سرعت سایت فقط به Database ربط ندارد؟

قبل از اینکه Database را مقصر بدانید، مسیر را پیدا کنید

یک هم‌تیمی page کندی را می‌بیند و فوراً می‌گوید: «باید برای Database index بسازیم.» شاید بعداً این تصمیم درست باشد، اما فعلاً evidence کافی نداریم. Browser ممکن است منتظر image، stylesheet، shared cache، origin response، application work یا data access باشد. حتی ممکن است Request مربوط به resource کند اصلاً به application یا Database نرسیده باشد.

در این درس Delivery & Cache Path Record v1 را می‌سازید. این record مسیر یک resource را دنبال می‌کند، observed fact را از hypothesis جدا نگه می‌دارد، private/shared reuse را تفکیک می‌کند و قبل از تغییر هر layer مشخص می‌کند چه evidence دیگری لازم است.

هدف محدود است: محل احتمالی latency را پیدا کنید بدون اینکه Cache، CDN، Server یا Database را به پاسخ همیشگی تبدیل کنید.

از دو درس قبل فقط boundary لازم را حمل کنید

WEBF-001 prerequisite سخت است: boundary میان Browser و Server و مدل Request/Response را نگه دارید و فراموش نکنید یک page معمولاً چند resource دارد. WEBF-004 prerequisite نرم است: بدانید یک responsibility ممکن است قبل از Request، هنگام رسیدگی به Request یا بعداً در Browser رخ دهد؛ اما کل آن درس را اینجا تکرار نکنید.

مالکیت این page فقط cache و delivery-path reasoning در canonical تقسیم‌شده WEB-000 است. این درس cache configuration، راه‌اندازی vendorهای CDN، database tuning، framework API یا performance engineering کامل را آموزش نمی‌دهد و chapter exit را نیز نمی‌بندد.

به‌جای یک bottleneck، هر resource را روی چند boundary دنبال کنید

مدل پایه چنین است:

Browser / private cache. cache اختصاصی یک کاربر می‌تواند طبق HTTP cache semantics، response ذخیره‌شده را برای Request مناسب reuse کند. RFC 9111 private cache را از shared cache جدا می‌کند. [S-RFC9111]

Shared cache / delivery intermediary. shared cache می‌تواند response را برای بیش از یک کاربر reuse کند، البته فقط تحت محدودیت‌های caching. CDN یک delivery system توزیع‌شده است؛ nodeهای آن می‌توانند copyهای content را نگه دارند و برای بعضی resourceها مسیر تحویل را تغییر دهند، اما CDN مترادف HTTP cache و تضمین performance نیست. [S-RFC9111] [S-MDN-CDN]

Origin / server application. اگر intermediary پاسخ Request را تأمین نکند، مسیر می‌تواند به origin ادامه پیدا کند. Origin ممکن است resource ازقبل‌تولیدشده را سرو کند یا هنگام Request کار فعلی انجام دهد. [S-MDN-WEB]

Data boundary. application ممکن است Database یا data source دیگری را بخواند، ولی فقط وقتی path واقعاً به آن responsibility برسد. پس hypothesis مربوط به Database باید از path evidence بیاید، نه صرفاً از جمله «page کند است».

این مدل per-resource است. HTML، CSS، JavaScript، image، font و API Requestهای بعدی می‌توانند در یک page experience مسیرهای متفاوتی داشته باشند.

reuse، freshness، correctness و latency را چهار سؤال جدا بدانید

Delivery & Cache Hypothesis Ledger جدول row-level داخل artifact اصلی یعنی Delivery & Cache Path Record v1 است و artifact دوم محسوب نمی‌شود. برای هر resource یا step این fieldها را ثبت کنید:

• Observed fact: چیزی که واقعاً از scenario یا evidence می‌دانید.
• Resource / path step: دقیقاً درباره کدام response یا boundary حرف می‌زنید.
• Cache role: فقط با cache evidence یکی از PRIVATE_CACHE، SHARED_HTTP_CACHE، NO_CACHE_ROLE_OBSERVED یا UNKNOWN را ثبت کنید.
• Delivery boundary: فقط با path evidence یکی از BROWSER_OR_USER_AGENT، CDN_OR_EDGE، ORIGIN_SERVER، DATA_BOUNDARY یا UNKNOWN را ثبت کنید. ممکن است یک CDN node هم shared HTTP cache باشد، اما این دو fact مترادف نیستند و باید جدا ثبت شوند.
• Latency hypothesis: محل احتمالی delay؛ تا وقتی evidence ندارید آن را fact ننویسید.
• Reuse evidence: آیا response ذخیره‌شده واقعاً Request را satisfy کرده یا با evidence موجود می‌تواند satisfy کند.
• Freshness/validation evidence: جدا ثبت کنید درباره freshness یا validation چه می‌دانید؛ reuse به‌تنهایی این evidence را ایجاد نمی‌کند.
• Correctness note: آیا content برای این user/Request از نظر معنایی درست است؛ از reuse به‌تنهایی نتیجه نگیرید.
• Uncertainty / constraint: چه چیزی هنوز معلوم نیست یا شرطی است.
• Next evidence: چه observationای hypothesis را تأیید یا رد می‌کند.
• Bounded decision: الان دقیقاً چه نتیجه محدودی می‌توان گرفت.

در RFC 9111، fresh بودن cache یعنی stored response در شرایط تعریف‌شده بدون validation قابل reuse است. این معنی فنی freshness به‌تنهایی ثابت نمی‌کند business data حتماً صحیح، مجاز برای همان user یا جدیدترین مقدار ممکن است. [S-RFC9111]

چرا shortcutهای رایج خراب می‌شوند

Cache hit یعنی reuse رخ داده؛ نه اینکه correctness ثابت شده

اگر stored response reuse شود، درباره delivery path evidence دارید. ولی هنوز ثابت نکرده‌اید personalization، authorization، invalidation یا business recency درست بوده است. این سؤال‌ها را جدا نگه دارید.

CDN می‌تواند یک بخش path را بهتر کند و بخش دیگر را دست‌نخورده بگذارد

MDN، CDN را مجموعه‌ای از serverهای توزیع‌شده برای تحویل copyهای data توضیح می‌دهد. همان صفحه به dependency و حتی شرایطی اشاره می‌کند که CDN می‌تواند performance را کاهش دهد. نتیجه محدود این است: «CDN delivery path را تغییر می‌دهد»، نه «CDN همیشه سایت را سریع‌تر می‌کند». [S-MDN-CDN]

HTML سریع مساوی page سریع نیست

Browser برای ساخت experience چند resource می‌گیرد. ممکن است HTML سریع برسد اما asset بزرگ یا Request بعدی بخش غالب زمان باشد. HTML و آن asset باید دو row جدا در Ledger داشته باشند. [S-MDN-WEB]

حتی slow origin response هم Database را به‌تنهایی ثابت نمی‌کند

اگر evidence نشان دهد delay بعد از رسیدن Request به origin است، candidateها محدودتر می‌شوند؛ اما application computation، upstream service، data access و serialization هنوز می‌توانند مسئولیت‌های متفاوت باشند. این درس implementation آن‌ها را آموزش نمی‌دهد؛ فقط جلوی پرش بدون evidence را می‌گیرد.

مثال‌ها: مسیر را تشخیص دهید، نه slogan را

مثال ۱ — stylesheet عمومی تکراری

یک stylesheet عمومی قبلاً در private browser cache ذخیره شده و طبق cache rules برای Request equivalent قابل reuse است. observation مفید این است که Browser ممکن است full response را بدون مراجعه دوباره به origin تأمین کند. bounded decision این نیست که «کل site cached است»؛ فقط می‌گوییم «برای این resource یک private-cache reuse path قابل‌دفاع وجود دارد». [S-RFC9111]

مثال ۲ — scenario واقعی؛ پاسخ عمداً داده نمی‌شود

scenario authoritative این است: HTML از shared cache سریع می‌رسد، اما یک asset بزرگ که Browser fetch می‌کند experience را کند می‌کند؛ هیچ database changeای نمی‌تواند این symptom را توضیح دهد. اینجا classification نهایی را کپی نکنید. فقط observed fact مربوط به HTML و asset را در Delivery & Cache Path Record v1 جدا ثبت کنید و مشخص کنید برای بستن path چه evidence دیگری لازم است. این case برای independent evidence work رزرو شده است.

contrast — origin HTML و static asset روی CDN

فرض کنید HTML به origin می‌رود اما static asset از یک CDN node تحویل می‌شود. چون هر دو متعلق به یک page هستند، path آن‌ها یکی نمی‌شود. تغییری که static asset را بهتر می‌کند به‌تنهایی چیزی درباره origin application یا Database time ثابت نمی‌کند.

دو misconception که باید completion را block کنند

Misconception 1: «page کند است، پس Database را optimize کن.» symptom هنوز resource و boundary را مشخص نکرده است. repair: ابتدا slow resource/Request را نام ببرید و بررسی کنید آیا آن path اصلاً به application/Database رسیده است.

Misconception 2: «Cache hit یعنی content درست و current است.» reuse/freshness semantics یک سؤال cache را جواب می‌دهد. semantic correctness و business recency evidence مستقل می‌خواهند. statement را به سه بخش reuse evidence، freshness/validation evidence و correctness evidence بشکنید. [S-RFC9111]

overclaim سوم هم رایج است: «CDN اضافه کن و latency حل می‌شود.» خود MDN tradeoffها را ذکر می‌کند؛ architectural statement باید بگوید کدام resource path تغییر می‌کند و کدام path اصلاً تغییر نکرده است. [S-MDN-CDN]

در architecture review، noun را به hypothesis قابل‌رد تبدیل کنید

به‌جای «مشکل Cache داریم» statementهایی از این جنس لازم است:

• «این HTML response شاید برای shared reuse eligible باشد؛ cache semantics و eligibility همین Request را بررسی کن.»
• «resource غالب بعد از HTML delivery توسط Browser fetch می‌شود؛ قبل از تغییر origin data access، delivery path همان resource را مشخص کن.»
• «Request به origin می‌رسد، اما evidence فعلی application computation را از data access جدا نکرده است.»

وقتی evidence کم است، UNKNOWN را حفظ کنید. UNKNOWN بهتر از layer assignment مطمئنی است که path آن را ثابت نمی‌کند. cache semantics و delivery location را مستقل نگه دارید: «از CDN تحویل شد» به‌تنهایی shared-cache reuse را ثابت نمی‌کند و shared-cache reuse هم به‌تنهایی CDN مشخصی را ثابت نمی‌کند.

انتخاب معتبر به semantics محتوا و evidence بستگی دارد

یک response ممکن است فقط برای یک user در private cache مناسب باشد، برای shared reuse eligible باشد، از CDN تحویل شود، مستقیم از origin بیاید یا عمداً reuse نشود. این‌ها maturity level نیستند و optimization ladder عمومی هم نیستند.

shared cache می‌تواند برای responseهای eligible، origin work تکراری را کم کند؛ اما shared reuse برای content user-specific می‌تواند نامناسب باشد. CDN ممکن است delivery را نزدیک‌تر کند یا بار بعضی Requestها را از origin کم کند و هم‌زمان dependency و connection path دیگری اضافه کند. برای resource دیگر، direct origin delivery ممکن است bounded choice صحیح باشد. [S-RFC9111] [S-MDN-CDN]

قاعده تصمیم: resource را دقیق نام‌گذاری کن، correctness constraint را نگه دار، candidate delivery path را مشخص کن و بعد بپرس چه evidenceای تصمیم را عوض می‌کند.

scaffold را در سه مرحله حذف کنید

مرحله ۱ — guided. برای یک public image، personalized HTML response و API response سه row جدا بسازید. cache role و delivery boundary را مستقل ثبت کنید. برای cache role از PRIVATE_CACHE، SHARED_HTTP_CACHE، NO_CACHE_ROLE_OBSERVED یا UNKNOWN و برای delivery boundary از BROWSER_OR_USER_AGENT، CDN_OR_EDGE، ORIGIN_SERVER، DATA_BOUNDARY یا UNKNOWN استفاده کنید. cache semantics و delivery location را در یک label ترکیبی ادغام نکنید.

مرحله ۲ — repair. هم‌تیمی قبل از مشخص‌کردن slow resource یک database index پیشنهاد می‌کند. پیشنهاد را به bounded hypothesis تبدیل کنید و یک missing-evidence note و یک non-claim بنویسید.

مرحله ۳ — independent. scenario HTML سریع/asset کند را بدون layer hint حل کنید. Delivery & Cache Path Record v1 را با observed fact، candidate latency location، uncertainty، next evidence و حداقل دو non-claim کامل کنید. واژه‌های CDN، Cache یا Database فقط وقتی مجازند که path evidence آن‌ها را پشتیبانی کند.

evidence قابل‌قبول چه شکلی است

Delivery & Cache Path Record v1 کامل باید:

1. browser/private-cache، shared-cache/CDN، origin/server و data boundaryهای مرتبط را map کند بدون اینکه ادعا کند هر Request حتماً همه را طی می‌کند؛
2. observed fact را از latency hypothesis و architecture decision جدا کند؛
3. cache reuse/freshness را از semantic correctness جدا نگه دارد؛
4. uncertainty و next evidence را بنویسد؛
5. حداقل دو non-claim صریح داشته باشد؛
6. claimهای current را فقط به سه source اعلام‌شده متصل کند؛
7. مالکیت کل WEB-000 یا C01 chapter exit را ادعا نکند.

coding Lab لازم نیست، چون construct این درس diagnosis و bounded decision است، نه implementation execution.

نردبان Assessment

1. Retrieval: private/shared cache، CDN delivery، origin/server و data boundary را بدون ساختن یک path اجباری از هم جدا کنید.
2. Application: symptom یک page چند-resource را به rowهای مستقل تبدیل کنید و observed را از hypothesis جدا کنید.
3. Diagnosis: claimی را repair کنید که cache reuse را با correctness/currentness یکی می‌گیرد.
4. Decision: برای scenario جدید یک cache/delivery decision محدود بگیرید و evidence باطل‌کننده را بنویسید.
5. Transfer: case authoritative را حل کنید که HTML از shared cache سریع است اما asset بزرگ Browser-fetched experience را غالباً کند کرده و database change نمی‌تواند آن symptom را توضیح دهد.

Diagnosis، decision و transfer blocking هستند. product/vendor name evidence نیست. پاسخ نهایی باید uncertainty و non-claim را حفظ کند.

sourceهای اعلام‌شده و freshness boundary

این درس دقیقاً از سه source منجمدشده Bible استفاده می‌کند:

• S-RFC9111 — RFC 9111, HTTP Caching: storage/reuse semantics و distinction میان private و shared cache.
• S-MDN-CDN — MDN CDN glossary: مفهوم CDN delivery و tradeoffها؛ نه guarantee برای سریع‌ترشدن همه سایت‌ها.
• S-MDN-WEB — MDN How the web works: context سطح‌بالای Browser Request، Server Response، resource delivery و assembly در Browser.

هر سه در 2026-09-10 دوباره بررسی شدند و claim boundary Bible هنوز معتبر است. source set گسترش پیدا نکرد. review بعدی حداکثر تا 2026-12-31 یا زودتر در صورت تغییر material reference لازم است.

non-claim نهایی: CDN جای Database را نمی‌گیرد؛ Cache hit semantic correctness را ثابت نمی‌کند؛ اضافه‌کردن CDN همیشه سایت را سریع‌تر نمی‌کند؛ این درس مالک کل WEB-000 نیست.