API Gateway: Agent phục vụ qua REST/WebSocket — Khi agent trở thành microservice

Agent là quá trình hội thoại "sống" (long-running), nhưng web được xây dựng trên HTTP không trạng thái (stateless). Sự không khớp này tạo ra ma sát lớn: làm sao để stream token từ Claude hay GPT-4 về browser mà không rơi vào "polling hell"? Làm sao để agent chủ động gọi lại người dùng khi cần xác nhận? API Gateway pattern chính là cầu nối xử lý sự chuyển đổi giữa giao thức web ngắn hạn và agent trạng thái kéo dài, biến agent thành microservice có thể gọi qua REST hay WebSocket chuẩn hóa.

Vấn đề

Expose trực tiếp backend agent (Python, Node.js) ra browser gặp phải ba bức tường:

Bức tường giao thức: Browser nói HTTP request-response — gửi một gói, đợi trả về, đóng kết nối. Nhưng LLM generate token từ từ (streaming), người dùng muốn thấy từng chữ hiện ra thay vì chờ 10 giây rồi nhận cả đoạn. REST truyền thống không hỗ trợ streaming hiệu quả.

Bức tường trạng thái: Agent cần nhớ context (lịch sử chat, trạng thái tool đang chạy). Nếu mỗi request REST là stateless, bạn phải gửi lại toàn bộ history (tốn token) hoặc lưu session ở backend rồi đối mặt với sticky sessions khi scale horizontally — load balancer sẽ hỏng nếu request thứ 5 của user A rơi vào server khác với request thứ 4.

Bức tường thời gian thực: Agent đôi khi cần "gọi lại" — ví dụ sau 30 giải phương trình xong thì báo kết quả, hoặc hỏi xác nhận khi gặp câu hỏi mơ hồ. HTTP không cho phép server push chủ động xuống client đang chờ.

Cách tiếp cận cũ là polling: client hỏi "xong chưa?" mỗi 2 giây. Tạo độ trễ 2-4 giây, tốn bandwidth, nhanh chóng hit rate limit khi có 10,000 user đồng thời. Hoặc dùng WebSocket thô trực tiếp từ agent service — nhưng khi scale, ai quản lý 10,000 connection persistent? Ai xử lý $disconnect khi user mất wifi?

Ý tưởng cốt lõi

API Gateway đóng vai trò impedance matcher (khái niệm từ điện tử: khớp trở kháng giữa hai mạch). Ở đây, gateway khớp giữa "web infrastructure stateless" với "agent runtime stateful".

Kiến trúc tầng:

Browser/Mobile  →  API Gateway  →  Agent Runtime
     |                  |                |
   HTTPS/WSS      REST/WebSocket     gRPC/HTTP2
                      |
               DynamoDB/Redis (Connection IDs)

Gateway duy trì hai khuôn mặt:

• Mặt REST: /api/v1/agent/task cho tool-calling không trạng thái (ví dụ: "tính nhanh 2+2", trả về JSON ngay).
• Mặt WebSocket: /ws/stream cho hội thoại dài, streaming token, và callback hai chiều.

Cơ chế hoạt động chi tiết:

WebSocket Routes: AWS API Gateway (hoặc tương đương) định nghĩa các route đặc biệt:

• $connect: Khi client mở WebSocket, Lambda trigger lưu connectionId vào DynamoDB với TTL 15 phút. Đây là "session key".
• $disconnect: Dọn dẹp connection ID khi client đóng tab.
• $default: Mọi message từ client được forward đến agent service (qua SQS hoặc HTTP POST) để tránh timeout 30 giây của Gateway — agent xử lý bất đồng bộ, xong rồi dùng postToConnection API để stream token về client qua WebSocket đang mở.

Protocol Bridging: Gateway nhận WebSocket JSON frame, chuyển thành gRPC/HTTP2 gọi internal agent service. Agent stream token về (1-4KB chunks cho GPT-4o), Gateway gói thành WebSocket binary/text frames gửi về browser. User thấy từng token hiện ra mà không cần giữ connection trực tiếp đến GPU server.

Token-aware Rate Limiting: Khác với REST thông thường chỉ giới hạn "requests/phút", Gateway cho agent cần giới hạn tokens/phút (TPM) và context-window-per-connection — ngăn một user nào đó gửi 100K token context làm nghẽn GPU memory.

REST Fallback: Cho các tác vụ idempotent (kiểm tra số dư, tra cứu đơn hàng), Gateway route đến HTTP-triggered Lambda, tránh overhead của WebSocket.

Khoảnh khắc "à ra": WebSocket không chỉ là "cái ống nối dài cho HTTP". Nó biến architecture từ request-response sang session-based — giống như chuyển từ gửi thư (mỗi lá độc lập) sang gọi điện thoại (dây nối liên tục, có thể chen ngang, nhớ lịch sử).

Tại sao nó hoạt động

Logic thiết kế nằm ở tách biệt concerns:

Tách trạng thái kết nối khỏi business logic: Agent code không cần biết gì về connectionId, heartbeat, hay TLS termination. Gateway lo phần "nhà hàng" (tiếp khách, dẫn chỗ), agent lo "nấu ăn" (suy luận). Khi scale, bạn thêm node GPU phía sau, Gateway tự động load balance dựa trên connection count, không cần sticky sessions phức tạp.

Tách băng thông khỏi suy luận: WebSocket duy trì persistent connection nên không cần TLS handshake lặp lại (tiết kiệm 2-3 RTT mỗi message). Nhưng chi phí là $29/triệu message so với $3.50/triệu request REST (giá AWS). Đánh đổi này đáng giá cho UX real-time, nhưng bạn sẽ muốn dùng REST cho webhook nội bộ (agent gọi API bên ngoài không cần stream).

Tách auth khỏi compute: Gateway xác thực JWT/API key trước khi request đến backend GPU đắt tiền. Một request không hợp lệ bị từ chối ở edge, không làm phiền agent logic.

So sánh với polling:

• Latency: WebSocket <100ms (tức thì) vs Polling 1000-2000ms (chờ vòng lặp).
• Cost compute: Polling tốn CPU ở cả client lẫn server vì request vô nghĩa; WebSocket chỉ truyền khi có data.
• Độ phức tạp: WebSocket cần xử lý reconnect logic, heartbeat, và "last writer wins" khi có nhiều tab — Gateway giải quyết phần này cho bạn.

Trade-off quan trọng: Lambda-backed agents có cold start 100-500ms — không chấp nhận được cho voice real-time. Bạn cần dùng ECS/EKS hoặc Provisioned Concurrency cho Gateway pattern này.

Ý nghĩa thực tế

B2B Integration: Agent của bạn trở thành microservice chuẩn. Đối tác gọi POST /api/v1/agent/analyze-contract cho xử lý đồng bộ (trả về sau 30s), hoặc mở WebSocket /ws/agent-stream để nhận cập nhật tiến độ phân tích 20 trang tài liệu theo thời gian thực.

Benchmark thực tế:

• AWS API Gateway: xử lý hàng trăm nghìn concurrent connections, cold start <100ms khi kết hợp Lambda.
• WebSocket cost cao gấp ~8x so với REST nhưng giảm perceived latency 70-90% cho end-user.
• Protocol bridging cho phép 10,000+ concurrent persistent connections trên một Gateway instance mà không làm cạn kiệt TCP limits của GPU nodes.

Ai đang dùng:

• OpenAI API: REST với SSE (Server-Sent Events) fallback cho streaming.
• Claude API: Persistent connections qua HTTP/2 tương tự WebSocket behavior.
• Azure AI Foundry: Expose MCP (Model Context Protocol) servers qua API Management, coi agent như API entity hạng nhất.
• AWS Bedrock Agents: Pattern Lambda + API Gateway để tích hợp với mobile apps.

Hạn chế — những gì Gateway KHÔNG làm:

• Không phải AI Gateway: Gateway truyền thống không hiểu semantic caching (lưu prompt tương tự) hay routing giữa nhiều model (GPT-4 vs Claude). Cần thêm lớp AI Gateway như Kong AI Gateway hoặc Cloudflare AI Gateway phía trước.
• Timeout cứng: AWS API Gateway giới hạn WebSocket idle timeout tối đa 2 giờ — agent chạy multi-day cần logic heartbeat/reconnect ở client.
• Cold start: Lambda-backed agents có độ trễ khởi động 100-500ms, không phù hợp voice real-time (cần provisioned concurrency hoặc EKS).

Đào sâu hơn

Tài liệu chính thức:

• AWS API Gateway WebSocket API — Hướng dẫn cấu hình $connect, $disconnect và DynamoDB cho connection ID persistence.
• Azure API Center Key Concepts — Theo dõi A2A agents và MCP servers như API definitions.

Bài viết liên quan TroiSinh:

Cùng cụm Channels & Integration:

Đọc tiếp:

• Thiết lập & Chạy agent đầu tiên — Nếu bạn chưa có agent chạy để expose qua Gateway (Level 0).
• Scheduling & Automation — Kết hợp API Gateway với Cron Jobs để agent tự động "thức dậy" và gọi API bên ngoài.
• Use Cases thực chiến — Các pattern triển khai production với Gateway ở quy mô lớn (Level 2).

Mở rộng:

• AWS Serverless WebSocket APIs — Video kiến trúc pattern Gateway + Lambda + DynamoDB cho connection state.
• APIsec SSRF Guide — Bảo mật Gateway cho agent khỏi SSRF attacks khi agent có thể gọi URL do user cung cấp.