Mở rộng và triển khai: cân bằng tải, cụm dịch vụ backend, blue/green và canary

1. Bài này nói về điều gì và vì sao quan trọng

Hãy tưởng tượng bạn để GiftGenius ở giai đoạn nó sống đơn độc trên Vercel, một instance MCP‑gateway (đồng thời triển khai MCP ra bên ngoài và gọi vào các dịch vụ REST của bạn), một backend cho agents, mọi thứ “chạy được”. Điều đó còn tạm ổn với pet project và 100 người dùng đầu tiên.

Nhưng ngay khi OpenAI đưa App của bạn lên Store và bất ngờ được featured trên trang chủ trước Giáng Sinh, “một gateway trên cổng 3000” sẽ thành câu chuyện buồn: hàng đợi lệnh gọi tool, timeout, lỗi 500, tụt hạng trên Store và email từ marketing kiểu “tại sao hệ thống chết đúng giờ cao điểm bán hàng?”.

Mục tiêu của chúng ta trong bài này là học cách nghĩ về GiftGenius (và bất kỳ ChatGPT App nào) như một hệ thống gồm nhiều instance giống hệt nhau phía sau một bộ cân bằng tải. Thêm nữa — hiểu các chiến lược phát hành cẩn trọng và một sơ đồ rõ ràng “làm sao để rollback nếu có trục trặc”.

2. Mở rộng theo chiều ngang và thiết kế stateless

Bắt đầu từ ý tưởng cơ bản: nếu MCP Gateway hoặc dịch vụ backend nội bộ của bạn lưu trạng thái quan trọng trong bộ nhớ của tiến trình cụ thể, gần như không thể mở rộng ngang một cách tử tế.

Mở rộng theo chiều dọc vs chiều ngang

Trước hết làm rõ thuật ngữ.

Mở rộng theo chiều dọc — là khi bạn “bơm cơ” cho một máy chủ: thêm CPU, thêm RAM. Nhanh, đôi khi rẻ lúc khởi đầu, nhưng có trần cứng và biến một instance thành single point of failure: khi con “quái vật” đó ngã, mọi thứ ngã theo.

Mở rộng theo chiều ngang — là khi bạn chạy nhiều bản sao dịch vụ phía sau cân bằng tải. Mỗi instance tương đối nhỏ, không giữ trạng thái quan trọng trong bộ nhớ, còn trạng thái đưa ra kho bên ngoài (Postgres, Redis, object storage). Có thể thoải mái thêm/bớt instance theo tải.

Với MCP Gateway và các dịch vụ backend (Gift REST API, Commerce REST API, Analytics Service / REST API, v.v.) mở rộng ngang hầu như là bắt buộc: ChatGPT có thể bất ngờ đổ vào bạn lượng traffic gấp nhiều lần (mùa vụ, promo trên Store, một video TikTok viral), và bạn chỉ việc thêm instance, không phải “cầu mong một server chịu nổi”.

Stateless là gì trong bối cảnh MCP Gateway và các backend

Để mở rộng ngang hiệu quả, dịch vụ phải càng stateless càng tốt.

Stateless trong ngữ cảnh của chúng ta nghĩa là:

• dịch vụ không lưu trong bộ nhớ trạng thái người dùng độc nhất, sống lâu, mà logic nghiệp vụ phụ thuộc vào nó;
• mọi trạng thái quan trọng nằm trong DB, hàng đợi, cache, hoặc kho S3‑tương tự bên ngoài;
• nếu một instance cụ thể sập, instance khác có thể tiếp tục phục vụ người dùng bằng cách “nhặt” ngữ cảnh từ kho bên ngoài.

Với GiftGenius, điều này có nghĩa là:

• lịch sử gợi ý quà, like/dislike và giỏ hàng của người dùng nằm, ví dụ, trong Postgres;
• hàng đợi tác vụ dài (tạo gợi ý hàng loạt, gửi email gợi ý) nằm trong broker như Redis/Cloud Queue;
• nếu có dịch vụ riêng cho workflow agent phức tạp, nó lưu checkpoint và bộ nhớ sống lâu trong store riêng, không phải RAM của một tiến trình.

Instance MCP Gateway hay bất kỳ dịch vụ backend nào trở thành “bò sữa chứ không phải thú cưng”: có thể giết và tạo lại không thương tiếc mà không mất dữ liệu nghiệp vụ.

Ví dụ mini: chuyển trạng thái từ bộ nhớ sang kho bên ngoài

Giả sử trước đây bạn làm một MCP tool rất đơn giản add_to_cart, qua gateway gọi vào logic nội bộ và logic đó lưu giỏ hàng trong bộ nhớ tiến trình (đúng là demo đôi khi làm vậy — và ổn miễn là bạn hiểu không được làm thế trên production):

// TỆ: giỏ hàng lưu trong bộ nhớ của tiến trình dịch vụ backend
const inMemoryCarts = new Map<string, string[]>();

export async function addToCart(userId: string, sku: string) {
  const cart = inMemoryCarts.get(userId) ?? [];
  cart.push(sku);
  inMemoryCarts.set(userId, cart);
  return cart;
}

Mở rộng ngang ở đây là bất khả: một request vào instance A, request khác vào instance B, và giỏ của người dùng sẽ khác nhau.

Phương án đúng — đưa giỏ hàng ra DB hoặc cache bên ngoài. Ví dụ (đơn giản hoá):

// TỐT: giỏ hàng ở kho lưu trữ bên ngoài
import { db } from "./db";

export async function addToCart(userId: string, sku: string) {
  await db.cartItems.insert({ userId, sku }); // đơn giản hoá
  const cart = await db.cartItems.findMany({ where: { userId } });
  return cart;
}

Giờ thì không quan trọng instance backend nào xử lý request đi qua gateway: giỏ hàng là thống nhất cho tất cả.

3. Cân bằng tải: traffic đi vào các cụm backend như thế nào

Ngay khi bạn có hơn một instance dịch vụ, cần ai đó phân phối request giữa chúng. Giống như bộ phận điều phối trong tiệm pizza nổi tiếng: nhiều shipper, nhiều khách, không có logic là hỗn loạn.

L4 vs L7, và vì sao ta chủ yếu quan tâm L7

Bộ cân bằng tải có thể hoạt động ở các lớp khác nhau:

• L4 (TCP/UDP) chỉ chuyển byte từ client đến một trong các backend, không thực sự hiểu đó là giao thức gì;
• L7 (HTTP) hiểu trước mặt là HTTP request, có thể nhìn path, header, cookie, đôi khi cả body.

Với kiến trúc ChatGPT App gồm MCP Gateway và các dịch vụ REST, ta hầu như luôn cần L7 LB: mọi thứ giao tiếp qua HTTP/SSE, và ta muốn định tuyến theo path, domain, header (ví dụ cho canary releases) và làm health checks.

Health checks và loại instance “ốm” khỏi vòng quay

Bộ cân bằng tải cần kiểm tra định kỳ các instance còn sống không. Cách đơn giản nhất — có endpoint GET /health hoặc /readyz trả về 200 OK nếu mọi thứ ổn.

Trong dịch vụ Node/TypeScript hoạt động như MCP Gateway hoặc backend, health check có thể như sau:

// apps/gateway/src/http/health.ts
import { type Request, type Response } from "express";

export function healthHandler(req: Request, res: Response) {
  res.json({
    status: "ok",
    version: process.env.RELEASE_ID ?? "dev",
  });
}

Bộ cân bằng tải gõ vào /health mỗi N giây. Nếu trả lời bắt đầu là 5xx hoặc timeout, instance đó bị loại khỏi vòng quay và traffic mới sẽ không đi vào đó.

Lưu ý cho Streaming / SSE

MCP Gateway khá thường xuyên dùng SSE (Server‑Sent Events), đặc biệt nếu bạn stream kết quả từng phần. LB cần:

• hỗ trợ kết nối HTTP dài hạn;
• biết cách tính các kết nối này khi chọn instance (một số LB có thể tính số kết nối đang mở, không chỉ RPS).

Điều này quan trọng vì một lệnh gọi tool “dài dòng”, stream text 2 phút, sẽ treo dưới dạng kết nối hoạt động. Nếu có quá nhiều kết nối như vậy trên một instance, cần tạm “giảm tải” instance đó — gửi kết nối mới sang nơi khác.

4. Cụm dịch vụ backend: tách theo nhiệm vụ, không gom tất cả vào một chỗ

Bước hợp lý tiếp theo — ngừng nghĩ về “một backend lớn” và chia hệ thống thành nhiều cụm theo tính chất tải và độ quan trọng.

Ví dụ kiến trúc GiftGenius theo cụm

Tổng hợp dữ liệu từ module 16 gợi ý sơ đồ sau cho GiftGenius:

Về bản chất, đây là hiện thực hoá mẫu bulkheads (vách ngăn): nếu cụm B bất ngờ “đốt CPU bằng token” khi tạo văn bản phức tạp, cụm C phụ trách thanh toán vẫn hoạt động vì có pool tài nguyên và cơ chế mở rộng riêng.

Trông như thế nào qua Gateway

MCP Gateway, được mô tả trong bài đầu của module, thấy toàn bộ traffic MCP vào và định tuyến chúng theo các cụm backend. Đại khái như sau:

• lệnh gọi tool list_gifts, suggest_gifts → cụm A (Gift REST API);
• lệnh gọi tool generate_greeting_card hoặc agent workflow phức tạp → cụm B (Agents REST service hoặc workers);
• các công cụ create_order, confirm_payment → cụm C (Commerce REST API).

Đằng sau đó có thể là một LB chung hoặc nhiều LB (ví dụ một L7‑LB riêng trước commerce để cô lập hơn nữa).

Có thể minh hoạ tổng quan:

flowchart LR
    ChatGPT((ChatGPT))
    GW[MCP Gateway]
    LBA[LB Gift API Cluster A]
    LBB[LB Agents/Workers Cluster B]
    LBC[LB Commerce API Cluster C]

    A1[Gift REST API A-1]
    A2[Gift REST API A-2]
    B1[Agents Service B-1]
    B2[Agents Service B-2]
    C1[Commerce REST API C-1]
    C2[Commerce REST API C-2]

    ChatGPT --> GW
    GW -->|tools: gifts| LBA
    GW -->|agents workflows| LBB
    GW -->|commerce| LBC

    LBA --> A1
    LBA --> A2
    LBB --> B1
    LBB --> B2
    LBC --> C1
    LBC --> C2

Sơ đồ hơi lý tưởng hoá, nhưng phản ánh nguyên tắc chính: các loại tải khác nhau — các cụm backend khác nhau, phía sau một MCP Gateway.

5. Chiến lược triển khai: vì sao cần blue/green và canary

Giờ chuyển sang cách cập nhật tất cả những thứ này sao cho người dùng không nhận ra, còn bạn có thể ngủ ngon mỗi đêm.

Phản ví dụ: deploy đè trực tiếp lên production

Chiến lược đơn giản nhất và nguy hiểm nhất: bạn lấy cụm đang chạy (ví dụ, cụm Gift REST API A), chạy image mới chồng lên cái cũ, thay container hoặc khởi động lại process.

Vấn đề ở đây:

• khi một phần instance đã mới, phần khác vẫn cũ, hệ thống có thể cư xử khó lường (đặc biệt nếu schema DB thay đổi);
• nếu có sự cố, rollback = một lần deploy “như trước”, có thể mất vài phút;
• tại thời điểm deploy hoàn toàn có thể có downtime ngắn khi chưa instance nào kịp lên.

Trong Kubernetes và PaaS, rolling update giúp đỡ đôi chút, nhưng ý tưởng chung vẫn thế: nếu không có chiến lược rõ ràng, bạn có nhiều “vùng xám”, nơi các phiên bản khác nhau xử lý traffic cùng lúc.

Triển khai Blue/Green: hai môi trường và chuyển mạch tức thì

Blue/Green — cách tiếp cận có hai môi trường gần như giống hệt tồn tại đồng thời: Blue (production hiện tại) và Green (phiên bản mới).

Quy trình phác thảo:

1. Triển khai phiên bản mới (v2) vào môi trường Green: cùng bộ gateway + các cụm backend, chỉ là chưa nhận traffic thực.
2. Chạy mọi bài test cần thiết trên Green: autotest, smoke, kiểm thử thủ công qua ChatGPT Dev Mode.
3. Tới lúc phát hành, chuyển cấu hình cân bằng tải/định tuyến để 100% traffic thật đi vào Green.
4. Blue vẫn sống bên cạnh như “sân bay dự phòng”. Nếu có vấn đề, chuyển traffic về lại chỉ trong vài giây.

Với GiftGenius, bạn có thể có mcp-gateway-blue.example.com và mcp-gateway-green.example.com. ChatGPT App ở production “trỏ” vào MCP endpoint chính thức (gateway), và khi phát hành bạn đổi cấu hình DNS/LB để domain mcp-gateway.example.com trỏ sang green.

Ưu điểm:

• chuyển qua lại tức thì;
• mọi vấn đề có thể xử lý sau khi đã rollback;
• không có trạng thái “nửa cụm mới, nửa cụm cũ”.

Nhược điểm:

Trong lúc phát hành phải giữ hai môi trường đầy đủ, tức chi phí tài nguyên ×2. Vì vậy chiến lược này thường áp dụng cho dịch vụ backend quan trọng — ví dụ cụm commerce C và chính MCP Gateway, nơi không được phép làm hỏng checkout hay điểm vào hệ thống.

Canary releases: “chim hoàng yến” trong mỏ than

Canary — phương án tiết kiệm hơn: bạn không nâng hai production đầy đủ, mà tung bản mới dần dần cho một phần nhỏ traffic và quan sát kỹ.

Kịch bản ví dụ:

1. Deploy phiên bản v2 của cụm Gift REST API A vào cùng pool hoặc một pool nhỏ dành cho canary.
2. Cấu hình LB hoặc MCP Gateway sao cho, ví dụ, 1% lệnh gọi tool liên quan đến quà đi vào v2, còn 99% — vào v1.
3. Theo dõi metric: error rate, latency, các metric kinh doanh đặc thù (conversion, checkout thành công).
4. Nếu ổn — tăng dần tỉ lệ: 1% → 5% → 10% → 50% → 100%. Nếu có vấn đề — rollback khẩn cấp.

Trong bối cảnh ChatGPT Apps, canary đặc biệt hữu ích không chỉ cho code, mà còn cho thử nghiệm với prompts: phiên bản mới của system prompt cho agent service có thể thay đổi hành vi rất mạnh, tốt nhất nên kiểm tra trước trên một mẫu người dùng nhỏ.

Gateway hoặc LB có thể quyết định request nào là “canary” dựa trên:

• ngẫu nhiên (ví dụ 1% tất cả request);
• theo userId (một phần người dùng vào thử nghiệm cố định);
• theo header hoặc cookie đặc biệt (cho nội bộ test).

Ví dụ nhỏ về logic định tuyến bằng pseudo‑TypeScript (minh hoạ ý tưởng trong gateway):

// Pseudocode trong Gateway: canary ngẫu nhiên đơn giản 5%
function routeToGiftBackendCluster(ctx: { userId?: string | null }) {
  const rnd = Math.random();
  if (rnd < 0.05) {
    return "gift-api-v2"; // canary
  }
  return "gift-api-v1";   // stable
}

Trong thực tế bạn sẽ không làm qua Math.random() trong runtime, mà đưa quy tắc vào config/feature flag, nhưng logic tương tự: một phần traffic đi vào canary version của backend, phần còn lại — vào bản ổn định.

6. Rollback là phần bắt buộc của chiến lược

Ngày xưa tôi rút ra một nguyên tắc hay: rollback phải nhanh hơn fix.

Nghĩa là nếu sau phát hành lỗi xuất hiện và người dùng kêu “mọi thứ hỏng hết”, đừng anh hùng sửa bug trên production. Hãy nhấn nút đỏ to “rollback”.

Trong các nền tảng như Vercel (nơi ta đã triển khai phần Next.js của GiftGenius), điều này rất tự nhiên: mỗi deploy là một artifact bất biến, và Vercel cho phép rollback nhanh về bản trước.

Với MCP Gateway và các cụm backend triển khai trên Kubernetes hay orchestrator khác, vai trò này do kubectl rollout undo đảm nhiệm: bạn quay về tập pod/image trước đó.

Điều chính — log và hiển thị phiên bản đang phục vụ traffic. Ví dụ có thể:

• thêm version vào /health và các endpoint chẩn đoán khác (ta đã làm ở trên);
• đẩy định danh bản phát hành qua header vào log (ví dụ X-Release-Id).

Ví dụ nhỏ: Next.js API route trả về phiên bản build để ChatGPT App nội bộ kiểm tra trong widget:

// apps/web/app/api/version/route.ts
export async function GET() {
  return Response.json({
    version: process.env.RELEASE_ID ?? "dev",
    builtAt: process.env.BUILT_AT ?? "unknown",
  });
}

Endpoint như vậy hữu ích cho debug: bạn có thể hỏi instance production xem chính xác phiên bản nào đang chạy, khỏi phải đoán “build cuối đã được deploy chưa?”.

7. Capacity planning: cần bao nhiêu instance cho GiftGenius

Ta đã bàn cách phát hành an toàn (blue/green, canary) và rollback nhanh khi có sự cố. Còn câu hỏi thực tế: cần bao nhiêu instance và cụm nào ở production để chịu tải thật mà không đốt quá nhiều tiền?

Không sa đà vào công thức, nhưng cần đôi chút. Mở rộng phải gắn với tải và kinh tế: bao nhiêu request mỗi ngày/giây, bao nhiêu lệnh gọi LLM nặng, chúng tốn bao nhiêu tiền mỗi ngày.

Đơn giản nghĩ theo bậc độ lớn:

• với 10k request/ngày cho GiftGenius (khoảng 0.1 RPS trung bình) bạn dễ dàng chạy với một‑hai instance MCP Gateway và vài instance Gift REST API/Agents workers;
• với 100k request/ngày (1–2 RPS trung bình, đỉnh cao hơn) nên có 3–5 instance gateway + cụm Gift REST API, cụm B riêng cho agents nặng và cụm commerce tách biệt;
• với 1M request/ngày (hàng chục RPS, tải đỉnh vào dịp lễ) chắc chắn cần cụm hoá, tài nguyên riêng cho LLM agents, cache mạnh và tầng edge (sẽ có bài riêng).

Đây không phải con số cứng, mà là cách buộc bạn ước lượng bậc độ lớn của tải và suy nghĩ trước: nút thắt ở đâu, sẽ mở rộng ra sao, và chi phí bao nhiêu.

Với GiftGenius, đặc biệt cần chuẩn bị cho mùa lễ: Năm mới, Giáng Sinh, Lễ Tình nhân, Black Friday. Tải có thể tăng gấp nhiều lần, và bạn muốn hệ thống chịu được.

8. Ví dụ mini thực tiễn: tiến hoá triển khai GiftGenius

Để ghép mọi thứ lại, hãy phác thảo tiến hoá triển khai GiftGenius.
Tại đây ta áp dụng tuần tự mọi thứ đã nói: thiết kế stateless cho gateway và các backend, cân bằng tải, cụm tách biệt và chiến lược phát hành (blue/green, canary).

Mức cơ bản: một gateway + backend trên Vercel/Kubernetes

Ở một thời điểm trong khoá học bạn đã làm điều này: một ứng dụng Next.js với Apps SDK trên Vercel, trong đó có cả MCP endpoint và logic backend đơn giản (Gift/Commerce) trong một dịch vụ. Khá đơn khối.

Ưu điểm rõ ràng: đơn giản, rẻ, ít chỗ để sai.

Nhược điểm duy nhất nhưng chí mạng: không thể mở rộng cho tải lớn và xử lý cập nhật kém.

Mức 2: tách MCP Gateway + nhiều cụm backend

Bước kế tiếp:

• tách MCP Gateway thành một dịch vụ riêng (Node/Go/NGINX+Lua, tuỳ);
• chạy nhiều instance Gift REST API (cụm A) và nhiều worker/dịch vụ cho agents (cụm B);
• tách commerce thành dịch vụ riêng (cụm C), có thể dùng DB/hạ tầng riêng.

Tại đây bật cân bằng tải L7, health checks và nếu có thể thì mở rộng ngang.

Mức 3: Chiến lược phát hành

Tại mức này bạn thêm:

• Blue/Green cho cụm commerce C (và nếu muốn, cho MCP Gateway), để checkout và xác thực ổn định tối đa;
• Canary cho các cụm Gift REST API và agent service, giúp thử nghiệm bản mới của tool và agents một cách an toàn mà không “giết” toàn bộ production.

Sơ đồ:

flowchart LR
    ChatGPT((ChatGPT))
    GWBlue[Gateway Blue]
    GWGreen[Gateway Green]
    LB[Traffic Switch]

    subgraph Prod
      LB --> GWBlue
      LB -.canary,% .-> GWGreen
    end

    ChatGPT --> LB

Thực tế có thể phức tạp hơn (Blue/Green chỉ cho commerce, canary chỉ cho cụm gift), nhưng ý tưởng là: bạn luôn biết phiên bản nào đi đâu, trong khi với ChatGPT mọi thứ vẫn trông như một MCP gateway duy nhất.

9. Một vài đoạn mã cho versioning và chẩn đoán

Ta đã thấy health endpoint và /api/version. Thêm ví dụ ghi log phiên bản và cụm trong handler MCP tool ở phía gateway, để dễ “gộp” metric.

Giả sử tool suggest_gifts được triển khai như REST endpoint trong Gift REST API và được gọi qua gateway:

import { type McpToolHandler } from "@modelcontextprotocol/sdk";

export const suggestGifts: McpToolHandler<{
  occasion: string;
  budget: number;
}> = async ({ input, meta }) => {
  const releaseId = process.env.RELEASE_ID ?? "dev";
  const clusterId = process.env.CLUSTER_ID ?? "gift-api-A";

  console.log("[suggest_gifts]", {
    releaseId,
    clusterId,
    userId: meta.userId,
    occasion: input.occasion,
  });

  // Tại đây MCP Gateway gọi Gift REST API theo bảng định tuyến,
  // còn bản thân tool chỉ là một lớp bọc mỏng quanh lời gọi REST
  return {
    content: [{ type: "text", text: "Gift ideas..." }],
  };
};

Ở đây chúng ta:

• đọc RELEASE_ID và CLUSTER_ID từ biến môi trường;
• ghi chúng vào log có cấu trúc;
• dễ dùng chúng cho phân tích: “ở phiên bản/cụm nào hiện lỗi nhiều hơn?”.

Từ góc nhìn ChatGPT App điều này hoàn toàn trong suốt, nhưng với bạn là lập trình viên — cực kỳ hữu ích, đặc biệt khi kết hợp với canary/blue‑green.

10. Những lỗi thường gặp khi mở rộng và triển khai ChatGPT App

Lỗi #1: lưu trạng thái session/người dùng trong bộ nhớ của gateway hoặc backend process.
Cách này giết chết mở rộng ngang: ngay khi có instance thứ hai, trạng thái sẽ “bị chia đôi” giữa chúng. Đặc biệt nguy hiểm là lưu trong bộ nhớ giỏ hàng, kết quả tìm kiếm hoặc tiến độ workflow. Tất cả phải nằm trong kho bên ngoài — DB, cache hoặc store chuyên dụng cho trạng thái của agent.

Lỗi #2: nghĩ rằng “một server mạnh” là đủ.
Mở rộng dọc tiện lúc khởi đầu nhưng tệ khi tăng trưởng thật: máy có giới hạn vật lý, một process thành single point of failure, và ChatGPT có thể mang đến spike traffic khó lường. Với MCP Gateway và các cụm backend, gần như luôn cần thiết kế stateless và nhiều instance sau LB.

Lỗi #3: tung bản mới “đè lên production” mà không có chiến lược rõ ràng.
Nếu bạn chỉ cập nhật container/process trong cụm đang chạy, bạn sẽ có trạng thái trung gian nơi một phần traffic vào bản cũ, phần còn lại vào bản mới, và khi lỗi xảy ra, rollback biến thành “deploy lại thêm lần nữa”. Đáng tin cậy hơn là giữ hai môi trường (blue/green) hoặc ít nhất một phiên bản canary của backend nhận một phần nhỏ traffic.

Lỗi #4: không có kế hoạch rollback nhanh.
Kịch bản xấu: phát hành xong, metric đỏ, người dùng phàn nàn, bạn mới bắt đầu nghĩ cách rollback. Kịch bản đúng: chuẩn bị sẵn khả năng rollback tức thì (công tắc blue/green, rollout undo, Vercel rollback), định danh phiên bản rõ ràng trong log và health endpoint, và nguyên tắc “rollback trước, điều tra sau”.

Lỗi #5: một cụm “làm hết” không tách theo loại tải.
Nếu tạo lời chúc (LLM agents) và checkout sống trong cùng một cụm, bất kỳ vấn đề nào phía model (độ trễ, timeout, tăng token) cũng có thể làm gãy thanh toán. Tách thành các cụm theo nhiệm vụ (Gift REST API / công cụ nhẹ, dịch vụ Agents nặng, Commerce REST API) và giới hạn/tài nguyên riêng cho mỗi cụm là bước quan trọng để tăng độ bền.

Lỗi #6: kiến trúc không gắn với kinh tế.
Rất dễ bị cuốn theo “nâng thêm vài node”, quên rằng mỗi lệnh gọi LLM và mỗi instance đều tốn tiền. Không có capacity planning tối thiểu (ước lượng tải và chi phí) có thể dẫn đến hoặc thiếu mở rộng và làm sập production, hoặc thừa mở rộng và mất biên lợi nhuận. Hãy liên kết số request, tỷ lệ thao tác LLM nặng và chi phí hosting với metric kinh doanh của ứng dụng.