LLMs đang làm lung lay nền tảng kiến trúc hệ thống hai thập kỷ qua

LLMs và các tác nhân AI (AI Agents) đang âm thầm phá vỡ giả định thiết kế hệ thống lâu đời, nơi máy chủ không trạng thái (stateless) và cơ sở dữ liệu là trung tâm. Cần một kiến trúc mới hỗ trợ tính toán có trạng thái (stateful) và tương tác hai chiều thời gian thực.

Kiến trúc "Cloud-native" đang gặp khủng hoảng

Trong hai thập kỷ qua, kiến trúc "cloud-native" đã được xây dựng dựa trên một giả định cốt lõi: trạng thái (state) nằm trong cơ sở dữ liệu, và tính toán (compute) là không trạng thái (stateless). Nếu muốn mở rộng quy mô, bạn sẽ mở rộng cơ sở dữ liệu theo chiều dọc (mua máy chủ mạnh hơn) hoặc thiết kế schema phân vùng dữ liệu, đồng thời mở rộng các máy chủ ứng dụng theo chiều ngang (thêm nhiều máy hơn).

Trong mô hình này, bất kỳ yêu cầu nào cũng có thể được gửi đến bất kỳ máy chủ nào; bộ cân bằng tải (load balancer) không cần quan tâm, và cơ sở dữ liệu đóng vai trò là nguồn sự thật duy nhất (single source of truth).

Tại sao LLMs lại phá vỡ quy tắc?

Tuy nhiên, LLMs và các tác nhân AI đang vi phạm giả định này và khiến kiến trúc truyền thống ngày càng khó vận hành. Sự thay đổi này không diễn ra một sớm một chiều, mà qua ba khía cạnh tinh vi:

• Công việc kéo dài (Long running work): Một tác nhân thực hiện nhiệm vụ kéo dài 10 phút không còn là một "yêu cầu" (request) thông thường, mà là một quy trình bất đồng bộ (async process) dài.
• Tính toán có trạng thái (Stateful compute): Một tác nhân có thể thực hiện nhiều vòng đối thoại, gọi nhiều công cụ (tool calls) và dựa vào ngữ cảnh tích lũy. Trạng thái này thực chất không phải là "trạng thái cơ sở dữ liệu", mà là bộ nhớ của tác nhân.
• Tương tác hai chiều: Người dùng muốn theo dõi quá trình suy nghĩ của tác nhân, có thể ngắt nó và thay đổi hướng đi. Đây là một cuộc hội thoại với một quy trình, không phải là một truy vấn đến một API không trạng thái và cơ sở dữ liệu.

Vấn đề của việc thực thi bền vững (Durable Execution)

Hiện tại, ngành công nghiệp đang giải quyết phần thực thi thông qua các công cụ hỗ trợ thực thi bền vững như Temporal, Inngest hay Restate. Chúng giúp quy trình trở nên bền bỉ và khả dụng. Tuy nhiên, chúng vẫn đang giả định rằng nền tảng bên dưới là không trạng thái. Điều này hoạt động tốt cho việc thực thi nhưng không giải quyết được vấn đề tương tác.

HTTP kết hợp với load balancer và máy chủ stateless không thể định tuyến (route) đến một quy trình cụ thể. Nó chỉ có thể định tuyến đến cơ sở dữ liệu. Vì vậy, ngay khi khách hàng muốn giao tiếp với một quy trình đang chạy trong framework thực thi bền vững, chúng ta quay lại bài toán định tuyến cũ. Kết quả là mọi người quay lại dùng cơ chế polling.

Polling một điểm cuối truy vấn để nhận các bản cập nhật mới mà quy trình đã ghi vào cơ sở dữ liệu là một giải pháp thay thế phổ biến, nhưng nó tồi tệ vì những lý do cũ kỹ: độ trễ do tần suất poll, tải lên cơ sở dữ liệu, lãng phí yêu cầu và trải nghiệm người dùng kém khi truyền dữ liệu dạng luồng (streaming).

Cuối cùng, việc polling coi cơ sở dữ liệu của bạn như một bus thông điệp. Đây là cách mọi người làm trước khi các bus thông điệp thực sự xuất hiện. Polling là việc bạn làm khi không thể xác định cách liên hệ với thứ bạn muốn nói chuyện. Nó chỉ là một cách giải quyết tạm thời cho vấn đề định tuyến.

Thiếu một nguyên lý định tuyến (Routing Primitive)

Giả định cơ bản về cách chúng ta xây dựng các dịch vụ web đang bị phá vỡ. Chúng ta đã thiết kế dựa trên kiến trúc này quá lâu đến mức quên mất rằng nó thực sự là một sự lựa chọn. Nhưng chúng ta đang thiếu một nguyên lý định tuyến cơ bản mà HTTP, load balancers và thiết kế máy chủ stateless không thể giải quyết.

Nguyên lý định tuyến mới

Chúng ta cần một tên định tuyến có thể chuyển tiếp, mà không phải là một máy chủ. Chúng ta muốn có khả năng nói: "gửi tin nhắn này đến bất kỳ ai đang tạo ra kết quả cho workflow X". Mà không cần biết đó là máy nào, bản sao máy chủ nào, hay quy trình nào.

WebSockets có phải là giải pháp?

Nhìn vào hình trên, có vẻ WebSockets có thể dễ dàng lấp vào chỗ trống được gắn nhãn "Routing primitive". WebSockets là phương thức truyền tải hỗ trợ kết nối hai chiều lâu dài, kết nối quy trình máy chủ với máy khách.

Tuy nhiên, WebSockets có một vấn đề: chúng là một kết nối, không phải là một địa chỉ. Chúng giải quyết vấn đề định tuyến một lần, bằng cách tạo kết nối trực tiếp giữa máy khách và máy chủ. Nhưng nếu kết nối đó bị ngắt, "địa chỉ" sẽ bị mất. Bạn không thể kết nối lại đến cùng một quy trình, vì bạn không có địa chỉ để định tuyến tới.

Giải pháp: Kênh Pub/Sub

Kênh Pub/Sub đảo ngược quyền sở hữu. Cả quy trình máy chủ lẫn máy khách đều không thể định tuyến trực tiếp. Chính phương thức truyền tải mới có thể định tuyến được. Cả máy khách và máy chủ đều kết nối đến kênh pub/sub theo tên, và nhận được sự giao tiếp hai chiều, có trạng thái. Kênh chính là địa chỉ, và không giống như WebSockets, nó không phải là một kết nối. Đó là một kênh bền vững mà bạn có thể ngắt kết nối và kết nối lại mà không mất dữ liệu hay khả năng định tuyến đến cùng một quy trình.

Kênh Pub/Sub bền vững

Phương thức truyền tải bền vững cho thực thi bền vững

Quay lại ví dụ về Temporal, hoạt động (hoặc bước) của quy trình làm việc bền vững sẽ kết nối đến một kênh pub/sub được đặt theo ID của quy trình đó. Máy khách sẽ kết nối đến cùng một kênh để nhận cập nhật, gửi tin nhắn ngắt hoặc điều hướng. Quy trình làm việc sẽ bền vững, và kênh cũng sẽ bền vững. Vì vậy, ngay cả khi quy trình hoặc kết nối máy khách bị ngắt, chúng vẫn có thể kết nối lại đến cùng một kênh và tiếp tục nói chuyện với nhau.

Bạn không phải luồn dữ liệu qua cơ sở dữ liệu, không phải poll, và không phải lo lắng về việc không thể định tuyến đến quy trình bền vững đang thực sự thực hiện công việc.

Kết luận

Thực chất, vấn đề này không chỉ nói về LLMs. LLMs chỉ làm cho vấn đề này trở nên rõ ràng hơn. Trước đây, nếu kết nối bị ngắt, yêu cầu sẽ đủ rẻ để thử lại (retry) và bạn có thể nhận được phản hồi xác định. Việc thử lại đơn giản hơn khi bạn mong đợi nhận được cùng một phản hồi cho cùng một yêu cầu.

Nhưng điều đó không đúng với LLMs. Phản hồi của LLM không xác định và không hề rẻ. Nếu bạn phải trả tiền cho các token (tokens), bạn không muốn lãng phí chúng chỉ vì máy khách đi vào hầm đường sắt và kết nối bị ngắt. Bạn cũng không muốn phải luồn từng token qua cơ sở dữ liệu chỉ để làm cho nó chống chịu được các sự cố kết nối của máy khách.

Bởi vì không xác định và tốn kém, LLMs làm cho các hạn chế của kiến trúc hiện tại trở nên rõ ràng hơn, và làm cho sự đánh đổi giữa HTTP + máy chủ stateless + load balancer + cơ sở dữ liệu trở nên đau đớn hơn.

Web không trạng thái (stateless web) không sai, nó chỉ không phải là thiết kế tốt cho các ứng dụng dạng tác nhân (agentic applications), những thứ cần các quy trình kéo dài, có trạng thái và tương tác. Chúng ta cần một kiến trúc mới bao gồm một nguyên lý định tuyến có thể định địa chỉ cho các quy trình, không chỉ cho cơ sở dữ liệu.

Thực thi bền vững + Pub/Sub + HTTP không trạng thái; mỗi thứ sẽ làm đúng công việc của mình.