Bài 8 — Ghép tất cả: kiến trúc tham chiếu & checklist go-live

Bảy bài trước cho bạn từng mảnh: serverless, container, queue, webhook, scaling, observability. Bài này ghép chúng thành một kiến trúc tham chiếu hoàn chỉnh và checklist để bạn tự tin bấm nút go-live.

Kiến trúc tham chiếu cho agent production

[Người dùng / hệ thống ngoài]
        |  (HTTP request hoặc webhook có ký)
        v
[API Gateway / Ingress] --> [Lớp tiếp nhận: serverless hoặc container nhẹ]
        |  verify + dedupe + tạo job_id (status=queued)
        v
     [QUEUE]  <----------- backpressure khi quá tải
        |  pull (visibility timeout > p95, heartbeat)
        v
[Worker Agent (container, autoscale theo độ sâu queue)]
   - idempotency guard
   - gọi LLM (concurrency limit, retry backoff+jitter, cache, model routing)
   - gọi tool (timeout, circuit breaker, fallback)
   - checkpoint tiến độ + trace_id xuyên suốt
        |  ghi kết quả -> DB, status=done
        v
[Thông báo: outbound webhook (ký + retry) / WebSocket / client polling]

Xuyên suốt: logs có cấu trúc + metrics (token, chi phí, p95, DLQ) + alert
Lỗi vĩnh viễn -> DLQ -> điều tra thủ công

Vì sao mỗi mảnh ở đúng chỗ

• Lớp tiếp nhận nhẹ: chỉ verify, dedupe, enqueue → trả nhanh, không bị timeout webhook (Bài 5).
• Queue ở giữa: tách nhanh/chậm, chịu tải gai, chống mất việc (Bài 4).
• Worker container: chạy tác vụ dài, autoscale theo queue, graceful shutdown (Bài 3).
• Serverless: dùng cho lớp tiếp nhận hoặc tác vụ ngắn co giãn về 0 (Bài 2).
• Scaling khôn: concurrency khớp rate limit LLM, cache, routing (Bài 6).
• Observability: trace_id, metrics chi phí, alert DLQ (Bài 7).

Ba tình huống thực tế và cách map

• Chatbot hỗ trợ realtime (cần streaming, độ trễ thấp): container service giữ ấm + WebSocket, không qua queue cho lượt ngắn; queue chỉ cho tác vụ nền như tạo ticket.
• Agent xử lý tài liệu dài (2–8 phút): API nhận → queue → worker container → outbound webhook báo xong. Bắt buộc idempotency + visibility timeout dài.
• Agent phản ứng sự kiện (Slack/Stripe/GitHub): webhook inbound (verify+dedupe) → queue → worker → phản hồi lại nền tảng. Đây là mô hình event-driven điển hình.

Checklist go-live (in ra và tick)

Kiến trúc & thời lượng

• [ ] Biết p95 thời gian agent; luồng > 25s đã async hóa.
• [ ] Lớp tiếp nhận trả < 1–2s, không chạy agent trực tiếp.

Queue & độ tin cậy

• [ ] Idempotency key cho mọi tác động phụ (email, đơn, thanh toán).
• [ ] Visibility timeout > p95 + heartbeat cho job dài.
• [ ] Retry backoff + jitter; có DLQ và alert.

Webhook

• [ ] Verify signature (compare_digest), dedupe theo event id.
• [ ] Outbound có retry, ký, và log delivery.

Scaling & chi phí

• [ ] Concurrency khớp rate limit LLM (RPM/TPM).
• [ ] Cache + model routing; cảnh báo ngân sách token.
• [ ] Backpressure khi queue quá sâu.

Vận hành

• [ ] Secrets trong secret manager, không hardcode.
• [ ] Graceful shutdown (SIGTERM) không rớt job.
• [ ] trace_id xuyên suốt; metrics token/chi phí/p95/DLQ.
• [ ] Timeout mọi lời gọi ngoài; circuit breaker + fallback.
• [ ] Runbook: DLQ đầy làm gì, LLM sập làm gì, chi phí vọt làm gì.

Khung ra quyết định cuối

Đồng bộ được? (p95<25s, không gai) -> Serverless đồng bộ
Dài / event-driven / tải lớn        -> API nhẹ + Queue + Worker container
Streaming realtime                  -> Container service + WebSocket
Luôn phủ lên: idempotency, timeout, observability, kiểm soát chi phí

Sai lầm thường gặp

• Go-live mà chưa test đường lỗi: giết worker, gửi webhook trùng, ép 429 — phải thử trước khi ra thật.
• Bỏ qua runbook: sự cố 2h sáng không ai biết xử lý DLQ hay LLM sập.
• Tối ưu sớm phần chưa phải nút thắt: nhớ mắt xích yếu nhất thường là LLM, không phải CPU.
• Chỉ test happy path: agent gặp input lạ/tool lỗi mới lộ vấn đề.
• Không đặt cảnh báo chi phí: phát hiện hóa đơn nổ qua email thanh toán thay vì alert.

Đến đây bạn đã có bức tranh trọn vẹn: từ chọn serverless/container, tách async bằng queue, nhận sự kiện qua webhook, scale theo rate limit, đến quan sát và phục hồi. Hãy áp checklist cho chính agent của bạn trước khi go-live.