Cache và lớp edge: CDN, edge cache, ETag, SWR, edge functions (Vercel) và các giới hạn của chúng

1. Vì sao cần quan tâm đến cache và edge trong ChatGPT App

Trong ứng dụng web cổ điển bạn cũng lo về tốc độ, nhưng người dùng ít ra còn thấy spinner. Với ChatGPT App thì thú vị hơn: người dùng trò chuyện với mô hình, đôi khi mô hình quyết định gọi App của bạn. Widget phải bật lên và nhanh chóng hiển thị điều gì đó hữu ích.

Thực tế khá rõ ràng: latency = tiền. Bạn trả lời càng lâu, khả năng người dùng rời đi càng cao, và những lần gọi LLM/backend dư thừa là chi phí trực tiếp cho mô hình và hạ tầng. Caching giúp giảm cả hai.

Đặc thù của ChatGPT Apps:

• Các yêu cầu từ ChatGPT tới App của bạn đi qua mạng và nhiều lớp trung gian. Mọi mili giây ở mỗi bước đều cộng dồn.
• Các endpoint MCP/HTTP có timeout thực (bao gồm Vercel serverless functions và edge functions). Nếu bạn không kịp, ChatGPT sẽ thấy lỗi và thậm chí có thể bắt đầu “hallucinate” câu trả lời.
• Nhiều dữ liệu trong GiftGenius không thay đổi từng giây: cấu trúc danh mục quà, tuyển chọn “ý tưởng hàng đầu” cho các phân khúc, cài đặt tính năng. Không cần thiết lần nào cũng đánh vào DB hay API bên ngoài.

Và đây là nơi những thứ sau phát huy tác dụng:

• CDN và edge cache, để phát nhanh static và JSON có thể cache.
• HTTP cache với Cache-Control/ETag/SWR, để các yêu cầu lặp lại nhanh hơn và rẻ hơn.
• Vercel Edge Functions, để thực hiện logic nhẹ gần ChatGPT và người dùng nhất có thể, nhưng không biến chúng thành “mini-backend”.

2. Giải phẫu độ trễ trong GiftGenius và các điểm có thể cache

Trước hết, nên phác thảo thẳng thắn xem latency sinh ra ở đâu.

sequenceDiagram
    participant User as Người dùng
    participant ChatGPT as ChatGPT
    participant App as ChatGPT App (Apps SDK)
    participant GW as MCP Gateway / Edge
    participant GiftAPI as Gift REST API / microservice quà tặng
    participant DB as Danh mục/CSDL

    User->>ChatGPT: "Hãy chọn quà cho anh trai"
    ChatGPT->>App: Gọi công cụ + render widget
    App->>GW: Yêu cầu HTTP/MCP (danh mục, tuyển chọn)
    GW->>GiftAPI: HTTP (REST)
    GiftAPI->>DB: Yêu cầu danh mục/khuyến nghị
    DB-->>GiftAPI: Phản hồi
    GiftAPI-->>GW: Phản hồi (JSON)
    GW-->>App: Phản hồi (JSON)
    App-->>ChatGPT: Widget với kết quả
    ChatGPT-->>User: Tin nhắn + UI

Có thể “rút ngắn đường” ở đâu?

1. Giữa ChatGPT và vành đai của bạn — CDN/edge cache (Vercel CDN/Edge Network), có thể phát các asset không đổi của widget và JSON có thể cache mà không cần vào origin server của bạn.
2. Giữa Gateway và các dịch vụ REST/HTTP nội bộ (Gift REST API, Commerce REST API, v.v.) và DB — cache ứng dụng (Redis/trong bộ nhớ/cache DB), để không lặp lại các yêu cầu giống nhau (ví dụ “danh sách danh mục quà tặng”) hàng chục lần.

Trong bài này chúng ta tập trung vào tầng HTTP/edge, vì nó gần ChatGPT và Vercel hơn.

3. Các loại cache trong kiến trúc của chúng ta

Vì kiến trúc dạng “bánh nhiều lớp”, nên cũng có nhiều tầng cache.

Giờ tập trung vào hai loại đầu tiên: HTTP cache + CDN/edge.

4. HTTP cache: Cache-Control, max-age và s-maxage

HTTP cache được điều khiển chủ yếu bằng header Cache-Control. Nó quyết định trình duyệt/client ChatGPT và/hoặc CDN có thể cache phản hồi của bạn và trong bao lâu.

Các điểm chính:

• max-age — số giây mà trình duyệt có thể cache phản hồi.
• s-maxage — số giây mà shared cache (CDN/proxy) có thể cache.
• public — phản hồi có thể cache trong shared cache.
• private — phản hồi chỉ dành cho một client cụ thể; CDN không cache nó.

Trong GiftGenius, ví dụ:

• JS/CSS/font của widget — các file có version (có hash trong tên), có thể trả về tự tin với Cache-Control: max-age=31536000, immutable.
• JSON với danh sách danh mục quà tặng — giống nhau cho mọi người dùng, khi đó hợp lý là public, s-maxage=60 (hoặc nhiều hơn).

Route Handler Next.js đơn giản cho GET /api/gifts/categories, được cache trên CDN trong 60 giây:

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

export const runtime = "nodejs"; // serverless function thông thường

export async function GET() {
  // ở đây có thể gọi DB/API bên ngoài
  const categories = [
    { id: "for_brother", title: "Quà cho anh/em trai" },
    { id: "for_mom", title: "Quà cho mẹ" },
  ];

  return NextResponse.json(categories, {
    headers: {
      // cho phép CDN cache 60 giây
      "Cache-Control": "public, s-maxage=60",
    },
  });
}

Vercel CDN sẽ lưu phản hồi trong 60 giây, và mọi yêu cầu của ChatGPT tới JSON này trong khoảng thời gian đó sẽ không chạm tới function của bạn. Nhanh và rẻ.

5. ETag: “dấu vân tay” nội dung và 304 Not Modified

ETag là “dấu vân tay” của tài nguyên, thường là hash của nội dung. Cách hoạt động:

1. Server trả phản hồi với header ETag: "v1-abc123".
2. Lần sau client gửi header If-None-Match: "v1-abc123".
3. Nếu server cho rằng nội dung không đổi, sẽ trả 304 Not Modified không có body.

Quan trọng: ETag tiết kiệm băng thông, nhưng không nhất thiết giảm latency, vì vẫn cần một vòng round trip tới server. Trong ngữ cảnh ChatGPT Apps, nó hữu ích với JSON nặng, nhưng đừng kỳ vọng tốc độ kỳ diệu chỉ từ ETag — để có tốc độ, tốt hơn là SWR và edge cache.

Ví dụ ETag đơn giản trong Route Handler Next.js (không dùng crypto‑hash để đỡ phức tạp):

// 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) {
    // Nội dung không thay đổi — trả 304
    return new NextResponse(null, { status: 304, headers: { ETag: ETAG } });
  }

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

Trong thực tế bạn sẽ tính ETag từ hash của dữ liệu hoặc dùng phiên bản bản ghi trong DB.

6. Stale‑While‑Revalidate (SWR): nhanh và đủ “tươi”

SWR là cách “hiển thị dữ liệu cũ ngay lập tức, còn dữ liệu mới thì nạp nền”. Có thể triển khai:

• Ở mức HTTP header Cache-Control với tham số stale-while-revalidate.
• Ở mức UI, dùng các thư viện như swr/react-query, giữ cache cục bộ và refetch nền.

SWR trong HTTP header

Header điển hình:

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

Ý nghĩa:

• Trong 60 giây đầu, CDN trả phiên bản mới.
• Từ giây 61 tới 360, CDN có thể trả phản hồi đã cũ ngay lập tức, đồng thời ở nền gửi yêu cầu tới origin để lấy phiên bản mới.
• Sau 360 giây, yêu cầu lấy nội dung mới trở thành blocking.

Người dùng (và ChatGPT) nhận phản hồi ngay cả khi tải cao, còn bạn cập nhật cache nhẹ nhàng ở nền. Với GiftGenius điều này rất lý tưởng, ví dụ cho “tuyển chọn quà top cho dịp Năm mới” — không thay đổi từng giây.

Ví dụ:

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

export async function GET() {
  const topGifts = [
    { id: "coffee_mug", title: "Cốc in chữ" },
    { id: "smart_led", title: "Đèn thông minh" },
  ];

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

SWR trong widget UI (React)

Widget GiftGenius sống trong sandbox của ChatGPT và có thể dùng bất kỳ code React nào. Bạn đã có thể gọi API của mình qua window.fetch. Thêm thư viện swr và tổ chức cache phía widget:

// 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 } // trong chat focus thay đổi khó lường, tắt đi
  );

  if (isLoading && !data) return <div>Đang tải ý tưởng...</div>;

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

Cách hoạt động:

• Lần render đầu sẽ gửi yêu cầu tới API của chúng ta.
• Kết quả được đưa vào cache của swr bên trong widget.
• Ở những lần render sau (hoặc các câu trả lời mới nơi ChatGPT chèn lại widget này với cùng key) dữ liệu lấy từ cache. Người dùng không thấy “nháy” hay spinner, còn cập nhật có thể chạy nền.

Như vậy, chúng ta kết hợp hai tầng SWR:

• Ở CDN/HTTP — để không tải origin.
• Ở UI — để không làm phiền người dùng.

Khi ghép tất cả lại:

• Đơn giản Cache-Control (max-age/s-maxage) — lớp cơ bản: cho CDN và client quyền cache phản hồi để giảm tải.
• ETag + If-None-Match — thêm khi cần tiết kiệm băng thông cho JSON nặng, chấp nhận round trip mạng.
• stale-while-revalidate — bật khi cần trả ngay cả dữ liệu hơi cũ (danh mục, tuyển chọn top).
• SWR ở UI (thư viện swr/react-query) — lớp riêng để làm mượt việc re-render và cache cục bộ trong sandbox của ChatGPT.

7. Nên cache gì trong GiftGenius và trong bao lâu

Hãy phân loại dữ liệu GiftGenius theo “tầng khả năng cache”.

Có thể cache ở tầng CDN/edge

Tất cả những gì giống nhau cho mọi người (hoặc các phân khúc lớn) và ít thay đổi:

• Static của widget: JS/CSS, font, icon — gần như “mãi mãi” (1 năm) với immutable.
• Cấu trúc danh mục quà: danh mục, mục, bộ lọc — vài phút/giờ.
• Tuyển chọn chung (“ý tưởng hay cho đồng nghiệp dưới 50$”) — vài phút/vài chục phút, đặc biệt khi cao điểm.

Ở đây rất phù hợp public, s-maxage + stale-while-revalidate.

Nên cache ở ứng dụng/Redis

Dữ liệu động hơn nhưng vẫn lặp lại:

• Kết quả của các API bên ngoài nặng (ví dụ tỷ giá, giá bán từ cửa hàng ngoài).
• Các phân khúc khuyến nghị được hỏi thường xuyên (theo giới/tuổi/dịp).

CDN không phải lúc nào phù hợp, vì dữ liệu có thể phụ thuộc token/tổ chức/tenant. Cache ở MCP Gateway hoặc dịch vụ REST nội bộ: bạn kiểm soát hoàn toàn và không trộn dữ liệu người dùng.

Không được cache (trong cache dùng chung)

Những gì gắn với người dùng cụ thể:

• Đơn hàng cá nhân và trạng thái.
• Thông tin thanh toán, địa chỉ, email.
• Khuyến nghị cụ thể dựa trên lịch sử đơn hàng riêng tư (nếu nhạy cảm).

Chỉ có thể cache ở tầng ứng dụng với ngữ nghĩa cẩn trọng (và tuyệt đối không rò rỉ giữa người dùng), nhưng chắc chắn không được cache public ở CDN.

8. Lớp edge: CDN so với edge functions

Đừng nhầm lẫn hai “loài” giống mà khác:

• CDN / edge cache — lưu trữ phản hồi đã tính sẵn, hầu như không có logic.
• Edge functions (Vercel Edge / Cloudflare Workers) — các đoạn mã nhỏ chạy trên các nút edge.

Kinh nghiệm cho thấy: Edge ≠ Serverless. Nhiều dev cố nhét vào đó logic nghiệp vụ nặng, gọi LLM và xử lý BLOB, rồi ngạc nhiên vì timeout và giới hạn. Edge functions:

• Khởi động rất nhanh (cold start gần như bằng 0).
• Nhưng bị giới hạn nhiều về CPU, thời gian chạy và API có sẵn (thường không có Node.js đầy đủ, không socket lâu, v.v.).

Khi nào edge function là ý tưởng hay

Trong bối cảnh GiftGenius và ChatGPT App, edge functions hữu ích cho:

• Định tuyến nhẹ: dựa trên header locale, x-openai-user-location hoặc tenant ID để quyết định gửi tới cụm backend khu vực nào.
• Thêm header đơn giản, feature flag, A/B routing.
• Endpoint read‑only nhanh, đọc dữ liệu từ edge‑KV hoặc từ CDN cache và hầu như không tính toán.

Khi nào edge function là ý tưởng tệ

• Các yêu cầu dài tới API bên ngoài.
• Gọi các mô hình LLM.
• Logic checkout phức tạp.
• Công cụ MCP với logic nghiệp vụ nặng.

Cho tất cả các việc đó, bạn có serverless functions thông thường của Next.js (ví dụ runtime = "nodejs") hoặc các dịch vụ/cụm riêng.

Ví dụ edge function trong Next.js 16

Tạo route nhỏ GET /api/geo-router, dựa vào header x-openai-user-location (giả định) để trả xem nên gõ vào cụm nào.

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

export const runtime = "edge"; // chạy trên edge

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",
    },
  });
}

Endpoint như vậy:

• Chạy rất nhanh (edge).
• Không làm gì phức tạp.
• Có thể được CDN cache.

9. Edge và cache trong kiến trúc tổng thể của GiftGenius

Ghép mọi thứ vào một sơ đồ.

flowchart TD
    ChatGPT[(ChatGPT / User)]
    CDN["CDN / Edge Cache (Vercel)"]
    EdgeFn["Edge Functions (định tuyến, feature flags)"]
    GW[MCP Gateway]
    GiftAPI["Gift REST API Cluster"]
    CommerceAPI["Commerce REST API Cluster"]
    DB[(DB/External APIs)]
    
    ChatGPT --> CDN
    CDN -->|cache hit| ChatGPT
    CDN -->|cache miss| EdgeFn
    EdgeFn --> GW
    GW --> GiftAPI
    GW --> CommerceAPI
    GiftAPI --> DB
    CommerceAPI --> DB

Kịch bản điển hình:

1. Widget ChatGPT yêu cầu /api/gifts/categories.
2. CDN kiểm tra cache. Nếu có phiên bản mới hoặc “stale nhưng vẫn dùng được” — trả ngay, không chạm EdgeFn/GW.
3. Nếu không có cache — yêu cầu rơi vào EdgeFn (nếu bật) và/hoặc đi thẳng tới GW.
4. GW khi cần dùng Redis cache nội bộ cho thao tác nặng hoặc gọi các dịch vụ REST nội bộ rồi xuống DB.
5. Phản hồi quay lại, vào CDN/edge cache và được phân phát cho người dùng khác.

Cách bố trí này:

• Giảm latency cho widget và ChatGPT.
• Giảm tải cho MCP Gateway và các cụm backend.
• Giảm chi phí gọi LLM/DB (ít yêu cầu lặp lại hơn).

10. Một vài mảnh thực hành cho GiftGenius

Cache danh mục + Next.js revalidate

Trước đó ta chỉ nói về API endpoint. Nhưng Next.js cũng có cơ chế tương tự cho chính các trang — qua ISR (revalidate).

Ví dụ server component lấy danh sách danh mục với revalidate = 60:

// app/(widget)/categories/page.tsx
export const revalidate = 60; // ISR: rebuild mỗi 60 giây

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>
  );
}

Trong production, Vercel sẽ tạo và cache HTML của trang này, hữu ích khi widget/giao diện của bạn mở không chỉ qua ChatGPT mà còn như một trang web thường (ví dụ debug panel hoặc landing).

Cache ứng dụng đơn giản trong dịch vụ backend

Đây không phải tầng edge, mà là cache ứng dụng (Redis/in‑memory bên trong Gift REST API hoặc dịch vụ backend khác). Nhưng tiện cho thấy nó trông như thế nào ở dạng đơn giản nhất:

// pseudo-code bên trong Gift REST API
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; // cache 60 giây
  }
  const data = await fetchRealCategories();
  cache.set(key, { ts: Date.now(), data });
  return data;
}

Khi chạy thực tế, bạn sẽ thay Map bằng Redis/Memcached, nhưng ý tưởng giống nhau: giảm lượt truy cập DB/API bên ngoài.

Nếu nén mọi thứ vào một mệnh đề: trước hết hãy quyết định rõ cái gì có thể cache và ở đâu (CDN, edge, Redis, DB), rồi mới bật các “công tắc kỳ diệu” của nền tảng. Cache không phải tick một ô cấu hình, mà là một phần của kiến trúc: nó tác động đến tốc độ, ổn định và chi phí.

11. Những sai lầm thường gặp khi làm việc với cache và lớp edge

Lỗi №1: “Cache tất cả cho nhanh”.
Kinh điển: dev đặt Cache-Control: public, s-maxage=3600 cho mọi phản hồi JSON. Vài giờ sau phát hiện một người dùng thấy đơn hàng của người khác, còn ChatGPT dùng dữ liệu tồn kho cũ. Với dữ liệu cá nhân hoặc nhạy cảm cần private cache, hoặc tắt hẳn CDN cache và giữ cache ở tầng ứng dụng với cách ly cẩn thận.

Lỗi №2: Nhầm giữa max-age và s-maxage.
Một số người chỉ đặt max-age và kỳ vọng CDN cache y hệt. Thực ra max-age chủ yếu dành cho trình duyệt, còn shared cache cần s-maxage. Kết quả là trình duyệt cache, nhưng CDN thì không, origin vẫn nghẹt thở dưới tải dù “đã bật cache”. Cách đúng — chỉ định rõ s-maxage cho CDN.

Lỗi №3: Kỳ vọng ETag tăng tốc mọi thứ.
ETag rất tốt để tiết kiệm băng thông, đặc biệt với JSON lớn, nhưng round trip mạng vẫn tồn tại. Trong thế giới ChatGPT App, mô hình vẫn chờ phản hồi từ server của bạn, dù là 304 không body. Nếu bạn cần giảm độ trễ, hãy dùng edge cache + SWR; ETag chỉ là cơ chế hỗ trợ.

Lỗi №4: Cố nhồi logic nghiệp vụ nặng vào edge functions.
“Gọi LLM ngoài, tính tuyển chọn phức tạp và gọi ba API ngoài ngay trong Vercel Edge — nhanh mà!” Sau đó là đau thương: giới hạn thời gian chạy, thiếu Node.js đầy đủ, lỗi kỳ lạ. Edge hợp với định tuyến nhẹ và A/B; mọi việc nặng hãy để serverless functions thường hoặc các cụm backend riêng.

Lỗi №5: Không có chiến lược vô hiệu hóa cache.
Đặt cache “1 giờ”, mọi thứ bay vù vù. Rồi business bảo: “đã đổi giá/danh mục/giới hạn, sao trong ChatGPT vẫn cũ?” Dev bắt đầu kéo tay gạt, xóa cache, restart dịch vụ. Với dữ liệu quan trọng, cần lên kế hoạch trước: sẽ xóa cache thế nào (theo webhook từ admin, theo version, theo key), chứ không trông chờ “tự mới sau 1 giờ”.

Lỗi №6: Bỏ qua mối liên hệ cache ↔ chi phí.
Đôi khi dev chỉ nghĩ cache là tốc độ. Trong hệ sinh thái LLM, nó còn là tiền: mỗi lần gọi mô hình và API ngoài đều tốn. Không có cache, MCP server có thể đập dịch vụ/mô hình ngoài quá thường xuyên khiến hóa đơn tháng làm bạn bất ngờ. Cache đúng cách giảm cả latency lẫn chi phí.

Lỗi №7: Trộn dữ liệu các locale/khu vực trong một cache.
GiftGenius hoạt động ở nhiều quốc gia nhưng dùng một key cache top_gifts. Hệ quả: người dùng ở Mỹ thấy giá rúp và cửa hàng Nga, còn người dùng ở châu Âu thấy đô la và cửa hàng Mỹ. Khi cache luôn cân nhắc các khóa như locale, currency, tenant trong tên key hoặc trong route (ví dụ /api/{locale}/gifts/top).

Lỗi №8: Phụ thuộc hoàn toàn vào “phép màu” của Next.js/nền tảng.
ISR, revalidate, CDN tự động — đều tuyệt. Nhưng nếu không hiểu chuyện gì diễn ra bên dưới, bạn dễ gặp hiệu ứng bất ngờ: trang hiển thị nội dung cũ còn API trả nội dung mới; ChatGPT thấy một đằng, người dùng trình duyệt thấy một nẻo. Hãy dành thời gian hiểu Cache-Control, ETag và mô hình SWR, còn Next.js là lớp bọc tiện dụng, không phải hộp đen.

Lỗi №9: Không phân biệt dev/staging/production về cache.
Trong môi trường dev, cache thường cản trở debug (“tôi vừa đổi dữ liệu, sao ChatGPT vẫn thấy tuyển chọn cũ?”). Hữu ích khi có cấu hình: ở dev gần như tắt cache (hoặc TTL vài giây), còn production — bật cache mạnh. Nếu không, bạn sẽ hoặc phát điên khi phát triển, hoặc vô tình deploy production không cache và hứng bão yêu cầu vào các cụm backend sau MCP Gateway.