Tôi đã xây dựng và vận hành microservices từ thời chúng còn gọi là "SOA phiên bản 2.0". Cách tiếp cận không thay đổi nhiều qua nhiều năm: chia nhỏ theo domain, expose REST hoặc gRPC, scale horizontally, monitor với Prometheus + Grafana. Rồi năm 2023, chúng tôi bắt đầu nhúng các AI service vào production và nhận ra rằng phần lớn những gì chúng tôi biết cần được xem lại.

Không phải vì AI là thứ gì đó huyền bí. Mà vì AI service có tập đặc tính phi chức năng hoàn toàn khác.

AI Services Khác Microservices Thông Thường Ở Điểm Gì

Microservice truyền thống: đưa cùng input, nhận cùng output. Deterministic. Bạn có thể cache, bạn có thể replay, bạn có thể test chính xác.

AI service: đưa cùng input, nhận output "tương tự nhưng không giống hệt." Non-deterministic. Stateful theo kiểu mà không service nào trước đây là stateful - nó mang theo toàn bộ conversation history trong context window. Và latency? Một inference call LLM tốt là 800ms. Tệ là 30 giây. Với streaming, người dùng có thể chấp nhận - nhưng khi bạn chain 3 AI call lại với nhau trong một request, bạn đang nói đến P95 latency vài chục giây.

Ba đặc tính này - non-deterministic, stateful, latency-sensitive - là gốc rễ của mọi vấn đề kiến trúc mà tôi sẽ nói đến.

Phần 1: Patterns Mới Cho AI Infrastructure

AI Gateway: Không Phải API Gateway Thông Thường

API Gateway chuẩn xử lý routing, auth, rate limiting. AI Gateway cần làm thêm:

  • Prompt injection detection: Người dùng cuối có thể cố gắng override system prompt. Bạn cần layer kiểm tra này trước khi prompt đến model.
  • PII scrubbing: Nếu user gửi CCCD số, tài khoản ngân hàng trong message, bạn không muốn những thứ đó đi vào log của LLM provider.
  • Model routing theo nội dung: Câu hỏi đơn giản đi GPT-4o mini, câu hỏi phức tạp đi Sonnet, câu hỏi cần reasoning đi o3.
class AIGateway:
    def route(self, request: AIRequest) -> ModelEndpoint:
        complexity_score = self.classifier.score(request.prompt)
        if complexity_score < 0.3:
            return ModelEndpoint.MINI  # $0.15/1M tokens
        elif complexity_score < 0.7:
            return ModelEndpoint.STANDARD  # $3/1M tokens
        else:
            return ModelEndpoint.REASONING  # $15/1M tokens

Trong 6 tháng đầu chạy rule-based routing như này, chúng tôi giảm được 65% chi phí LLM mà không ảnh hưởng đến chất lượng đo được qua user feedback.

Prompt Registry: Version Control Cho Prompt

Đây là thứ mà 90% team bỏ qua cho đến khi có incident. Prompt thay đổi là deployment. Nếu bạn hardcode prompt trong code và ship qua CI/CD, bạn đang coupling prompt iteration với code deployment cycle. Sai lầm này tốn của chúng tôi 2 tuần để unwind.

Prompt Registry là một service riêng quản lý:

  • Versioned prompts với semantic versioning
  • A/B testing giữa các phiên bản
  • Rollback không cần deploy lại code
  • Audit trail: ai thay đổi prompt gì, lúc nào
# prompt-registry.yaml
prompts:
  customer-support-v2.1.0:
    template: |
      Bạn là trợ lý hỗ trợ khách hàng của {company_name}.
      Nguyên tắc: {guidelines}
      ...
    parameters:
      company_name: required
      guidelines: required
    model_constraints:
      max_tokens: 1024
      temperature: 0.3

Model Router: Fallback Thông Minh

Khi OpenAI bị outage (và nó sẽ bị), bạn cần fallback. Nhưng không phải fallback ngây thơ "nếu OpenAI fail thì dùng Anthropic." Bạn cần semantic fallback - kiểm tra xem model thay thế có đủ capability cho task không.

Phần 2: Async-First Design Cho AI Workloads

Đây là nơi nhiều kiến trúc sư mắc lỗi nặng nhất. Họ thiết kế AI feature theo kiểu request-response đồng bộ vì đó là cách họ biết làm, rồi ngạc nhiên khi timeout xảy ra ở mọi nơi.

Rule ngón tay cái: Nếu AI task tốn hơn 3 giây, hãy thiết kế async từ đầu.

Pattern phù hợp:

Client → POST /ai/tasks → { task_id: "abc123", status: "queued" }
Client → GET /ai/tasks/abc123 → { status: "processing", progress: 0.4 }
Client → GET /ai/tasks/abc123 → { status: "done", result: {...} }

Hoặc dùng WebSocket/SSE để push kết quả về client thay vì polling.

Điều này cũng giải quyết vấn đề retry. Với async job queue, bạn có thể retry failed AI call mà không cần client biết. Với sync request, timeout là timeout - không có cơ hội retry trong suốt.

Một điểm quan trọng: queue của AI job không nên share với queue của regular job. AI job có độ ưu tiên, SLA, và resource consumption profile hoàn toàn khác. Tôi từng thấy một hệ thống mà AI job chiếm 80% queue và làm chết cả order processing pipeline.

Phần 3: Observability Cho AI - Beyond Logs Và Metrics

Prometheus và Grafana giỏi với những thứ numeric: request rate, latency, error rate. Với AI, bạn cần thêm một lớp nữa.

Những Gì Cần Track Mà Standard Observability Không Có

Token usage per request: Không chỉ tổng, mà breakdown input vs output tokens. Model pricing thường charge khác nhau cho hai loại này.

Prompt quality metrics: Tỉ lệ refusal (model từ chối trả lời), tỉ lệ hallucination phát hiện được qua grounding check, consistency score khi chạy cùng prompt nhiều lần.

Conversation health: Trong chatbot, context window có đang bị filled up không? Nếu có, compression strategy của bạn là gì?

# Structured logging cho AI calls
logger.info("ai_inference", extra={
    "model": "claude-sonnet-4-5",
    "prompt_tokens": response.usage.input_tokens,
    "completion_tokens": response.usage.output_tokens,
    "latency_ms": elapsed_ms,
    "task_type": "customer_support",
    "user_segment": user.segment,
    "refusal": response.stop_reason == "max_tokens",
    "cost_usd": calculate_cost(response.usage)
})

Điều tôi không thấy ở phần lớn team: Họ log AI calls nhưng không correlate được với business outcome. Token spent bao nhiêu mà user không satisfied? Feature X dùng LLM call đắt hơn feature Y 10 lần nhưng có thực sự cần thiết không? Đây là những câu hỏi observability của bạn phải trả lời được.

Phần 4: Circuit Breaker Và Fallback Cho AI Services

Circuit breaker pattern không mới. Nhưng áp dụng cho AI có một số đặc thù.

Threshold không nên chỉ là error rate. LLM có thể trả về HTTP 200 nhưng kết quả vô nghĩa. Bạn cần semantic health check: một canary prompt mà bạn biết expected output, chạy định kỳ để phát hiện model degradation trước khi user phàn nàn.

Fallback không phải luôn là "dùng model khác". Đôi khi fallback tốt nhất là:

  • Trả về cached response từ lần trước (nếu use case chấp nhận được)
  • Degrade gracefully về rule-based logic
  • Thông báo user "tính năng AI tạm thời không khả dụng" thay vì trả kết quả tệ
@circuit_breaker(
    failure_threshold=5,
    recovery_timeout=60,
    fallback=rule_based_classifier
)
async def ai_classify(text: str) -> Category:
    return await llm_client.classify(text)

Điều critical: test fallback thường xuyên. Netflix nổi tiếng với Chaos Monkey. Với AI service, bạn cần "LLM Chaos" - định kỳ inject failure vào AI calls để đảm bảo fallback path hoạt động và không bị rot.

Phần 5: Cost Attribution - Ai Trả Cho Token Của Service Nào

Đây là vấn đề organizational mà rất nhiều CTO bỏ qua cho đến khi nhận hóa đơn $50,000/tháng từ LLM provider và không biết số tiền đó đến từ feature nào.

FinOps cho AI là bắt buộc, không phải nice-to-have. Và nó cần được thiết kế vào architecture từ đầu.

Cơ chế tôi thấy hoạt động tốt:

  1. Cost center tagging: Mỗi AI call phải được tag với: team owner, product feature, user tier, environment.

  2. Budget alerts per feature: Feature A được cấp $500/ngày. Khi chạm 80%, alert. Khi chạm 100%, throttle hoặc degrade.

  3. Unit economics tracking: Không chỉ tổng cost mà cost per meaningful action - cost per completed ticket, cost per successful recommendation, cost per conversion.

# Cost attribution middleware
class CostAttributionMiddleware:
    async def __call__(self, request, call_next):
        with cost_context(
            team=request.headers.get("X-Team"),
            feature=request.headers.get("X-Feature"),
            user_tier=request.user.tier
        ):
            response = await call_next(request)
            return response

Một insight từ kinh nghiệm thực tế: khi team biết rõ feature của họ đang tốn bao nhiêu token, họ tự nhiên bắt đầu optimize prompt. Không cần mandate từ trên xuống. Visibility tạo ra accountability.

Kết Luận

Reference architecture cho AI-native application không phải là microservices với AI plugin thêm vào. Nó là một kiến trúc mới với AI Gateway, Prompt Registry, Model Router, async job pipeline riêng, observability layer hiểu token economics, circuit breaker có semantic health check, và cost attribution từ ngày đầu.

Phần lớn công việc không phải là AI engineering. Nó là platform engineering quen thuộc - nhưng với một tập constraint và failure mode mới. Team nào hiểu điều này sớm sẽ ship AI feature nhanh hơn và tốn ít tiền hơn những team đang cố gắng nhét AI vào kiến trúc cũ.

Chúng ta đang ở giai đoạn giống như 2014-2016 với microservices: mọi người đều biết đây là hướng đi, nhưng best practices vẫn đang được viết. Hãy học từ những người đi trước, nhưng đừng cargo-cult mọi thứ mà không hiểu tại sao.