Keş və edge qatı: CDN, edge-keş, ETag, SWR, edge-funksiya (Vercel) və onların limitləri

1. ChatGPT App-də niyə ümumiyyətlə keş və edge barədə düşünməliyik

Klassik veb tətbiqində də sürətə görə narahat olursunuz, amma orada istifadəçi heç olmasa spinner görür. ChatGPT App-də vəziyyət daha maraqlıdır. İstifadəçi modellə danışır, model bəzən sizin App-i çağırmağa qərar verir. Vidjet görünməli və kifayət qədər tez bir faydalı şey göstərməlidir.

Təcrübə kifayət qədər aydındır: latency = pul. Cavabınız nə qədər geciksə, istifadəçinin getmə ehtimalı bir o qədər çoxdur, artıq LLM/backend çağırışları isə modellər və infrastruktur üçün birbaşa xərclərdir. Keşləmə hər ikisini də azaldır.

Üstəlik, ChatGPT Apps-in spesifikası:

• ChatGPT-dən sizin App-ə sorğular şəbəkə və müxtəlif ara qatlardan keçir. Hər addımda hər hansı millisaniyə yığılır.
• MCP-/HTTP-endpoint-lərin real taymautları var (Vercel serverless-funskiyaları və edge-funskiyaları daxil olmaqla). Vaxtında çatmasanız, ChatGPT xəta görür və hətta uydurma cavablar yazmağa başlaya bilər.
• GiftGenius-da bir çox data hər saniyə dəyişmir: hədiyyə kataloqunun quruluşu, müxtəlif seqmentlər üçün «top-ideyalar» seçmələri, fıça ayarları. Hər dəfə yenidən bazaya və ya xarici API-yə getmək məntiqsizdir.

Və məhz burada ortaya çıxır:

• CDN və edge-keş — statikanı və keşlənə bilən JSON-u sürətlə vermək üçün.
• HTTP-keş Cache-Control/ETag/SWR ilə — təkrar sorğuları daha sürətli və ucuz etmək üçün.
• Vercel edge-funskiyaları — məntiqi maksimum dərəcədə ChatGPT-yə və istifadəçiyə yaxın yerdə, yüngül şəkildə icra etmək üçün, amma onları «mini-backend»ə çevirmədən.

2. GiftGenius-da gecikmələrin anatomiyası və keş nöqtələri

Əvvəlcə səmimi şəkildə çəkmək faydalıdır: latency ümumiyyətlə harada yaranır.

sequenceDiagram
    participant User as İstifadəçi
    participant ChatGPT as ChatGPT
    participant App as ChatGPT App (Apps SDK)
    participant GW as MCP Gateway / Edge
    participant GiftAPI as Gift REST API / hədiyyə mikroxidməti
    participant DB as Kataloq/Baza

    User->>ChatGPT: "Qardaşım üçün hədiyyə seç"
    ChatGPT->>App: Alətin çağırılması + vidjetin renderi
    App->>GW: HTTP / MCP sorğusu (kateqoriyalar, seçmələr)
    GW->>GiftAPI: HTTP (REST)
    GiftAPI->>DB: Kataloq/tövsiyələr sorğusu
    DB-->>GiftAPI: Cavab
    GiftAPI-->>GW: Cavab (JSON)
    GW-->>App: Cavab (JSON)
    App-->>ChatGPT: Nəticələrlə vidjet
    ChatGPT-->>User: Mesaj + UI

Burada harada sürəti artıra bilərik?

1. ChatGPT ilə sizin perimetriniz arasında — CDN/edge-keş (Vercel CDN/Edge Network), o, vidjetin dəyişməyən asset-lərini və keşlənən JSON-u origin serverinizə girmədən verə bilər.
2. Gateway ilə daxili REST-/HTTP-servislər (Gift REST API, Commerce REST API və s.) və baza arasında — tətbiq keşi (Redis/yaddaşda/BD-keş), məsələn, «hədiyyə kateqoriyalarının siyahısı» kimi eyni sorğuları on dəfə təkrarlamamaq üçün.

Bu mühazirədə biz məhz HTTP/edge qatına fokuslanırıq, çünki o, ChatGPT və Vercel-ə daha yaxındır.

3. Arxitekturamızda keş növləri

Arxitektura «laylı piroq» olduğuna görə, keşlər də bir neçəsidir.

İndi ilk iki üzərində cəmləşirik: HTTP-keş + CDN/edge.

4. HTTP-keş: Cache-Control, max-age və s-maxage

HTTP-keşi ilk növbədə Cache-Control başlığı idarə edir. Ondan asılıdır ki, brauzer/ChatGPT-klient və/və ya CDN cavabınızı keşləyə bilərmi və nə qədər müddətə.

Açar məqamlar:

• max-age — brauzerin cavabı neçə saniyə keşləyə biləcəyini göstərir.
• s-maxage — shared cache (CDN/proksi) üçün neçə saniyə olduğunu göstərir.
• public — cavabı shared-keşdə saxlamaq olar.
• private — cavab yalnız konkret müştəri üçündür; CDN onu keşləmir.

Məsələn, GiftGenius-də:

• Vidjetin JS/CSS/şriftləri — versiyalanmış fayllardır (addakı hash ilə), onları tam arxayınlıqla belə vermək olar: Cache-Control: max-age=31536000, immutable.
• Hədiyyə kateqoriyalarının siyahısı olan JSON — bütün istifadəçilər üçün eynidir, burada məntiqli seçim public, s-maxage=60 (və ya daha çox) olar.

GET /api/gifts/categories üçün Next.js Route Handler-in ən sadə nümunəsi; cavab CDN-də 60 saniyə keşlənir:

// app/api/gifts/categories/route.ts
import { NextResponse } from "next/server";

export const runtime = "nodejs"; // adi serverless-funksiya

export async function GET() {
  // burada BD-yə/xarici API-yə müraciət edə bilərdik
  const categories = [
    { id: "for_brother", title: "Qardaş üçün hədiyyələr" },
    { id: "for_mom", title: "Ana üçün hədiyyələr" },
  ];

  return NextResponse.json(categories, {
    headers: {
      // CDN-ə 60 saniyə keşləməyə icazə veririk
      "Cache-Control": "public, s-maxage=60",
    },
  });
}

Vercel CDN cavabı 60 saniyə saxlayacaq və bu pəncərə ərzində ChatGPT-dən həmin JSON üçün gələn bütün sorğular ümumiyyətlə sizin funksiyaya çatmayacaq. Bu, həm anidir, həm də ucuzdur.

5. ETag: kontentin barmaq izi və 304 Not Modified

ETag resursun şərti «barmaq izi»dir, adətən kontentin hash-i. İş sxemi belədir:

1. Server cavabı ETag: "v1-abc123" başlığı ilə qaytarır.
2. Növbəti dəfə müştəri If-None-Match: "v1-abc123" başlığını göndərir.
3. Server hesab edirsə ki, kontent dəyişməyib, o zaman bədənin (body) olmadan 304 Not Modified qaytarır.

Vacibdir: ETag trafikə qənaət edir, amma mütləq latency-i azaltmır, çünki serverə round trip yenə də lazımdır. ChatGPT App kontekstində bu, ağır JSON cavabları üçün faydalıdır, lakin təkcə ETag-dan möcüzəvi sürət gözləməyə dəyməz — bunun üçün SWR və edge-keş daha uyğundur.

Next.js handler-də sadə ETag nümunəsi (detala girməmək üçün kripto-hash-siz):

// app/api/gifts/config/route.ts
import { NextRequest, NextResponse } from "next/server";

const CONFIG = { version: 1, showExperimentalIdeas: true };
const ETAG = `"v${CONFIG.version}"`;

export async function GET(req: NextRequest) {
  const ifNoneMatch = req.headers.get("if-none-match");
  if (ifNoneMatch === ETAG) {
    // Kontent dəyişməyib — 304 qaytarırıq
    return new NextResponse(null, { status: 304, headers: { ETag: ETAG } });
  }

  return NextResponse.json(CONFIG, {
    headers: {
      ETag: ETAG,
      "Cache-Control": "public, s-maxage=300",
    },
  });
}

Real həyatda siz, əlbəttə, ETag-ı datanın hash-indən hesablayacaqsınız və ya BD-də yazının versiyasından istifadə edəcəksiniz.

6. Stale-While-Revalidate (SWR): sürətli və kifayət qədər təzə

SWR yanaşması «köhnəni dərhal göstər, yenisini fonda yenilə» deməkdir. Onu belə reallaşdırmaq olar:

• Cache-Control HTTP başlığında stale-while-revalidate parametrilə.
• UI səviyyəsində, swr/react-query kimi kitabxanalardan istifadə etməklə; onlar lokal keş saxlayır və fon refetch edir.

HTTP başlığında SWR

Tipik başlıq:

Cache-Control: public, s-maxage=60, stale-while-revalidate=300

Məna:

• İlk 60 saniyədə CDN təzə versiyanı verir.
• 61-ci saniyədən 360-cıya qədər CDN köhnəlmiş cavabı anında verə bilər, və fonda origin-dən yeni versiyanı gətirməyə başlayar.
• 360 saniyədən sonra yeni kontent üçün sorğu bloklayıcı olur.

İstifadəçi (və ChatGPT) hətta yükün pik vaxtında belə cavabı dərhal alır, siz isə fonda keş-i yumşaq şəkildə yeniləyirsiniz. GiftGenius üçün bu, məsələn, «Yeni il üçün top-hədiyyə seçmələri» kimi datalar üçün idealdır — onlar hər saniyə dəyişmir.

Nümunə:

// app/api/gifts/top/route.ts
import { NextResponse } from "next/server";

export async function GET() {
  const topGifts = [
    { id: "coffee_mug", title: "Yazılı fincan" },
    { id: "smart_led", title: "Ağıllı lampa" },
  ];

  return NextResponse.json(topGifts, {
    headers: {
      "Cache-Control": "public, s-maxage=60, stale-while-revalidate=300",
    },
  });
}

UI vidjetində SWR (React)

GiftGenius vidjeti ChatGPT qum qutusunda yaşayır və istənilən React kodundan istifadə edə bilər. Artıq window.fetch ilə öz API-nizi çağırmağı bacarırsınız. swr kitabxanasını əlavə edək və vidjet tərəfində keş təşkil edək:

// widget/GiftTopList.tsx
import useSWR from "swr";

const fetcher = (url: string) => fetch(url).then((r) => r.json());

export function GiftTopList() {
  const { data, isLoading } = useSWR(
    "https://api.giftgenius.com/api/gifts/top",
    fetcher,
    { revalidateOnFocus: false } // söhbətdə fokus qəribə dəyişir, söndürək
  );

  if (isLoading && !data) return <div>İdeyalar yüklənir...</div>;

  return (
    <ul>
      {data?.map((gift: any) => (
        <li key={gift.id}>{gift.title}</li>
      ))}
    </ul>
  );
}

Necə işləyir:

• İlk renderdə bizim API-yə sorğu gedir.
• Nəticə vidjet daxilindəki swr keşinə qoyulur.
• Təkrar renderlərdə (və ya yeni cavablarda, ChatGPT eyni açarla bu vidjeti yenə daxil edəndə) data keşdən götürülür. İstifadəçi «mıgılama» və spinnlər görmür, fonda isə yenilənmə gedə bilər.

Beləliklə, iki səviyyəli SWR birləşdiririk:

• CDN/HTTP səviyyəsində — origin-i yükləməmək üçün.
• UI səviyyəsində — istifadəçini yükləməmək üçün.

Hamısını bir yerdə toplasaq:

• Sadə Cache-Control (max-age/s-maxage) — bazis qat: CDN və müştərilərə cavabları keşləmək hüququ veririk və yükü azaldırıq.
• ETag + If-None-Match — ağır JSON üçün trafikə qənaət vacibdirsə əlavə edirik, amma şəbəkə round trip-i qəbul edirik.
• stale-while-revalidate — hətta bir az köhnəlmiş datanı anında vermək mühümdürsə (kataloqlar, top-seçmələr) aktivləşdiririk.
• UI-də SWR (swr/react-query kitabxanası) — vidjetin yenidən çəkilmələrini yumşaltmaq və ChatGPT qum qutusunda lokal keş üçün ayrıca qat.

7. GiftGenius-da nəyi və nə qədər müddətə keşləmək lazımdır

GiftGenius datalarını «keşlənmə qatları» üzrə qruplaşdıraq.

CDN/edge səviyyəsində keşləmək olar

Hamı üçün (və ya geniş seqmentlər üçün) eyni olan və nadir dəyişən hər şey:

• Vidjet statikası: JS/CSS, şriftlər, ikonlar — şərti olaraq «həmişəlik» (il) immutable ilə.
• Hədiyyə kataloqlarının strukturu: kateqoriyalar, bölmələr, filtrlər — dəqiqələr/saatlar.
• Ümumi seçmələr («iş yoldaşları üçün 50 $-dək ən yaxşı ideyalar») — dəqiqələr/onlarla dəqiqə, xüsusən pik mövsümlərdə.

Burada public, s-maxage + stale-while-revalidate ideal uyğun gəlir.

Tətbiqdə/Redis-də daha yaxşı keşləmək

Daha dinamik, amma yenə də təkrarlanan datalar:

• Xarici API-lərə ağır sorğuların nəticələri (məsələn, məzənnələr, xarici mağazadan aktual qiymətlər).
• Cins/yaş/vasitə üzrə tez-tez istənən tövsiyə seqmentləri.

Burada CDN həmişə uyğun olmur, çünki data token/organizasiya/tenant-dan asılı ola bilər. Keşi MCP Gateway və ya daxili REST-servislər səviyyəsində saxlayın: bu, tam sizin nəzarətinizdədir və müxtəlif istifadəçilərin datalarını qarışdırmır.

Keşləmək olmaz (ümumi keşlərdə)

Konkret istifadəçiyə bağlı olanlar:

• Şəxsi sifarişlər və onların statusları.
• Ödəniş məlumatı, ünvanlar, email.
• Şəxsi sifariş tarixçəsi əsasında konkret tövsiyələr (əgər həssasdırsa).

Bunu yalnız tətbiq səviyyəsində dəqiq semantika ilə (və mütləq istifadəçilər arasında sızma olmadan) keşləmək olar, amma public CDN-keşdə əsla yox.

8. Edge qatı: CDN və edge-funskiyalar

Bir-birinə bənzəyən, amma fərqli olan iki şeyi qarışdırmamaq vacibdir:

• CDN / edge-keş — əvvəlcədən hesablanmış cavabları saxlayır, məntiq demək olar ki, yoxdur.
• Edge-funskiyalar (Vercel Edge / Cloudflare Workers) — edge-nodelərdə işləyən kiçik kod parçalarıdır.

Təcrübə göstərir: Edge ≠ Serverless. Bir çox developer orada ağır biznes məntiqlərini, LLM çağırışlarını və BLOB emalını yerləşdirməyə çalışır, sonra isə taymautlara və limitlərə təəccüblənir. Edge-funskiyalar:

• Çox tez start verir (cold start demək olar ki, yoxdur).
• Ancaq CPU, icra müddəti və əlçatan API-lər üzrə ciddi məhdudiyyətləri var (tez-tez tam Node.js yoxdur, uzun soketlər və s.).

Edge-funksiya nə zaman yaxşı fikirdir

GiftGenius və ChatGPT App kontekstində edge-funskiyalar aşağıdakılar üçün faydalıdır:

• Yüngül marşrutlaşdırma: locale, x-openai-user-location və ya tenant ID başlıqlarına görə sorğunu hansı regional backend klasterinə yönləndirməyi müəyyənləşdirmək.
• Sadə başlıqlar, feature flag-lər, A/B marşrutlaşdırma əlavə etmək.
• Edge-KV və ya CDN-keşdən data oxuyan və demək olar ki, heç nə hesablamayan sürətli read-only endpoint-lər.

Edge-funksiya nə zaman pis fikirdir

• Uzunmüddətli xarici API sorğuları.
• LLM modellərinə çağırışlar.
• Checkout kimi mürəkkəb məntiq.
• Ağır biznes məntiqli MCP alətləri.

Bütün bunlar üçün sizdə adi Next.js serverless-funskiyaları var (məsələn, runtime = "nodejs") və ya ümumiyyətlə ayrıca servislər/klasterlər.

Next.js 16-da edge-funksiya nümunəsi

Şərti olaraq x-openai-user-location başlığına görə hansı regional klasterə müraciət olunacağını qaytaran kiçik GET /api/geo-router marşrutu yazaq.

// app/api/geo-router/route.ts
import { NextRequest, NextResponse } from "next/server";

export const runtime = "edge"; // edge-də icra edirik

export function GET(req: NextRequest) {
  const userLocation = req.headers.get("x-openai-user-location") ?? "US";
  const cluster =
    userLocation.startsWith("EU") ? "eu-gift-api" : "us-gift-api";

  return NextResponse.json({ cluster }, {
    headers: {
      "Cache-Control": "public, s-maxage=300",
    },
  });
}

Belə endpoint:

• Çox sürətli işləyir (edge).
• Heç nəyi mürəkkəbləşdirmir.
• CDN tərəfindən keşlənə bilər.

9. GiftGenius üçün ümumi arxitekturadakı edge və keş

Hamısını bir şəkilə yığaq.

flowchart TD
    ChatGPT[(ChatGPT / İstifadəçi)]
    CDN["CDN / Edge Cache (Vercel)"]
    EdgeFn["Edge Functions (marşrutlaşdırma, feature flag-lər)"]
    GW[MCP Gateway]
    GiftAPI["Gift REST API Cluster"]
    CommerceAPI["Commerce REST API Cluster"]
    DB[(DB/External APIs)]
    
    ChatGPT --> CDN
    CDN -->|keş hit| ChatGPT
    CDN -->|keş miss| EdgeFn
    EdgeFn --> GW
    GW --> GiftAPI
    GW --> CommerceAPI
    GiftAPI --> DB
    CommerceAPI --> DB

Tipik ssenari:

1. ChatGPT vidjeti /api/gifts/categories istəyir.
2. CDN keş-i yoxlayır. Orada təzə və ya «stale, amma hələ yararlı» versiya varsa — onu dərhal verir, EdgeFn/GW-ə toxunmadan.
3. Keş yoxdursa — sorğu EdgeFn-ə (aktivdirsə) və/və ya birbaşa GW-yə düşür.
4. GW lazım gələrsə ağır əməliyyatlar üçün daxili Redis-keşdən istifadə edir və ya daxili REST-servislərə, sonra BD-yə gedir.
5. Cavab geri qayıdır, CDN/edge-keşə düşür və digər istifadəçilərə paylanır.

Belə quruluş:

• Vidjet və ChatGPT üçün latency-ni azaldır.
• MCP Gateway və backend klasterlərinə düşən yükü azaldır.
• LLM/BD çağırışlarının dəyərini aşağı salır (təkrar sorğular az olur).

10. GiftGenius üçün kiçik praktik fraqmentlər

Kateqoriya keşi + Next.js revalidate

Buna qədər yalnız API-endpoint-lərdən danışdıq. Amma Next.js səhifələrin özləri üçün də oxşar mexanizmlər verir — ISR (revalidate) vasitəsilə.

revalidate = 60 olan kateqoriya siyahısını alan server component nümunəsi:

// app/(widget)/categories/page.tsx
export const revalidate = 60; // ISR: hər 60 saniyədən bir yenidən qururuq

async function fetchCategories() {
  const res = await fetch("https://api.giftgenius.com/api/gifts/categories");
  return res.json();
}

export default async function CategoriesPage() {
  const categories = await fetchCategories();
  return (
    <ul>
      {categories.map((c: any) => (
        <li key={c.id}>{c.title}</li>
      ))}
    </ul>
  );
}

Production-da Vercel bu səhifənin HTML çıxışını generasiya edib keşləyəcək; bu, vidjetiniz/interfeysiniz təkcə ChatGPT vasitəsilə deyil, adi veb səhifə kimi də açıldıqda (məsələn, debug paneli və ya landing) faydalıdır.

Backend-servisdə sadə tətbiq-keşi

Bu artıq edge qatı deyil, tətbiq keşidir (Redis/yaddaşda sizin Gift REST API və ya başqa backend-servisdə). Amma ən sadə formada necə göründüyünü göstərmək yerinə düşər:

// Gift REST API daxilində pseudo-code
const cache = new Map<string, any>();

async function getGiftCategories() {
  const key = "gift_categories_v1";
  const cached = cache.get(key);
  if (cached && Date.now() - cached.ts < 60_000) {
    return cached.data; // 60 saniyəlik keş
  }
  const data = await fetchRealCategories();
  cache.set(key, { ts: Date.now(), data });
  return data;
}

Döyüş şəraitində, əlbəttə, Map-i Redis/Memcached ilə əvəz edəcəksiniz, amma fikir eynidir: BD-yə/xarici API-yə daha az gedirik.

Bunu bir cümlədə desək: əvvəlcə dəqiq müəyyənləşdirin, nəyi və harada (CDN, edge, Redis, BD) keşləyə bilərsiniz, sonra platformanın «sehrli» flag-lərini aktivləşdirin. Keş sadəcə konfiqdə bir checkbox deyil, arxitekturanın bir hissəsidir: o, həm sürətə, həm sabitliyə, həm də pula təsir edir.

11. Keş və edge qatı ilə işləyərkən tipik səhvlər

Səhv №1: «Sürətli olsun deyə hər şeyi ard-arda keşləyirik».
Klassika: developer bütün JSON cavablarına Cache-Control: public, s-maxage=3600 qoyur. Bir neçə saatdan sonra məlum olur ki, bir istifadəçi digərinin sifarişlərini görür, ChatGPT isə məhsul mövcudluğu barədə köhnə datalarla işləyir. Fərdi və ya həssas datalar üçün ya private keş lazımdır, ya da CDN-keşi ümumiyyətlə söndürmək və keşi tətbiq səviyyəsində dəqiq izolasiya ilə saxlamaq.

Səhv №2: max-age və s-maxage arasında qarışıqlıq.
Bəziləri yalnız max-age qoyur və CDN-in də eyni müddətdə keşləyəcəyini gözləyir. Əslində max-age ilk növbədə brauzerə aiddir, shared-keş üçün isə s-maxage lazımdır. Nəticədə brauzer keşləyir, CDN isə yox və origin «keş qoyduq axı» deyə-deyə yük altında boğulur. Doğru yol — CDN üçün s-maxage-ı açıq şəkildə göstərməkdir.

Səhv №3: ETag-ın hər şeyi sürətləndirəcəyini gözləmək.
ETag xüsusilə böyük JSON faylları üçün trafikə əladır, amma şəbəkə round trip-i qalır. ChatGPT App dünyasında bu o deməkdir ki, model yenə də serverinizdən cavabı gözləyir, bədən olmadan 304 olsa belə. Sizə məhz gecikmə vacibdirsə, edge-keş + SWR lazımdır, ETag köməkçi mexanizmdir.

Səhv №4: Ağır biznes məntiqini edge-funskiyalara soxmağa cəhd.
«Gəlin, Vercel Edge-dən birbaşa xarici LLM-i çağıraq, mürəkkəb seçmələri hesablayıb üç xarici API-yə gedək — orada axı sürətlidir!» Sonra ağrı başlayır: icra vaxtı limitləri, normal Node.js-in olmaması, qəribə xətalar. Edge yüngül marşrutlaşdırma və A/B üçün yaxşıdır, ağır işlər isə adi serverless-funskiyalarda və ya ayrıca backend klasterlərində olmalıdır.

Səhv №5: Keşin etibarsızlaşdırma strategiyasının olmaması.
Bir saatlıq keş qoydunuz, hər şey uçur. Sonra biznes deyir: «qiymətləri/kateqoriyaları/məhdudiyyətləri dəyişdik, niyə ChatGPT-də hər şey köhnədir?» Developer-lər əllə qolları çırmağa, keşləri təmizləməyə və servisləri yenidən işə salmağa başlayır. Vacib datalar üçün öncədən düşünmək lazımdır: keşi necə atacaqsınız (admin-dən webhook ilə, versiya ilə, açara görə), «öz-özünə bir saata yenilənər» ümidi ilə yox.

Səhv №6: Keş ↔ xərc əlaqəsini görməzdən gəlmək.
Bəzən developer-lər keşi yalnız sürət kimi düşünür. LLM ekosistemində bu, həm də pul deməkdir: modelə və xarici API-yə hər artıq çağırış puldur. Keşsiz MCP server xarici servisi/modeli elə tez-tez döyə bilər ki, aylıq hesab sizi xoşagəlməz təəccübləndirsin. Düzgün keşləmə həm latency-i, həm də hesabı azaldır.

Səhv №7: Müxtəlif lokal/region datalarını eyni keşdə qarışdırmaq.
GiftGenius bir neçə ölkədə işləyir, amma keşdə top_gifts adlı bir açardan istifadə olunur. Nəticə: ABŞ istifadəçisi rubl və Rusiya mağazalarını, Avropa istifadəçisi isə dollar və ABŞ mağazalarını görür. Keşləmə zamanı həmişə locale, currency, tenant kimi açarları keş açarının adında və ya marşrutda (məsələn, /api/{locale}/gifts/top) nəzərə alın.

Səhv №8: Next.js/platformanın «sehrinə» tam arxayın olmaq.
ISR, revalidate, avtomatik CDN — hamısı əladır. Amma baş verənləri pərdəarxasında anlamasanız, gözlənilməz effektlər almaq asandır. Məsələn, səhifə köhnə kontent göstərir, API isə yenisini qaytarır; ChatGPT birini, brauzerdəki istifadəçilər isə başqa şey görür. Cache-Control, ETag və SWR nümunəsinin necə işlədiyini anlamağa vaxt sərf etməyə dəyər və Next.js-i qara qutu kimi yox, rahat örtük kimi istifadə etmək lazımdır.

Səhv №9: Dev/staging/production üzrə keş fərqinin olmaması.
Dev mühitində keş tez-tez debug-a mane olur («datamı dəyişmişəm, niyə ChatGPT hələ də köhnə seçmələri görür?»). Faydalıdır ki, dev-də keşi demək olar söndürən (və ya TTL-i bir neçə saniyə edən), production-da isə aqressiv keşləməni aktivləşdirən konfiqurasiya olsun. Əks halda ya inkişaf zamanı dələyə dönəcəksiniz, ya da təsadüfən proda keşsiz çıxıb, MCP Gateway arxasında daxili backend klasterlərinə sorğu qasırğası buraxacaqsınız.