💡 RetroLab đánh giá cao cách tiếp cận tối giản này, phù hợp với xu hướng giảm độ phức tạp hạ tầng trong phát triển phần mềm hiện đại. Tuy nhiên, cần lưu ý rằng tính bất đồng bộ của Litestream có thể không đáp ứng được yêu cầu về độ bền vững tuyệt đối trong một số hệ thống sản xuất quan trọng.
Gần đây, DBOS đã đưa ra một luận điểm thú vị: Postgres là tất cả những gì bạn cần cho durable execution – nếu bạn đã tin tưởng vào cơ sở dữ liệu của mình, thì không cần một tầng điều phối riêng biệt. Quan điểm này rất đáng chú ý, và có thể đẩy xa hơn nữa: đối với một lớp lớn các hệ thống bền vững, SQLite mới là thứ bạn thực sự cần.
Phần bền vững
Durable execution thường được thảo luận như thể nó đòi hỏi hạ tầng bền vững. Trong nhiều trường hợp, điều đó không đúng. Phần thực sự cần bền vững là trạng thái workflow. Compute có thể rẻ và dùng một lần. Đây là sự phù hợp tự nhiên với Obelisk: tiến trình workflow sống trong một execution log, workflow phát lại từ lịch sử đã được lưu, và các activity có thể thử lại. Điều quan trọng nhất là giữ trạng thái workflow tồn tại và dễ dàng kiểm tra.
Tại sao SQLite phù hợp
SQLite hấp dẫn vì nó cung cấp trạng thái giao dịch bền vững mà không cần giới thiệu một dịch vụ cơ sở dữ liệu riêng biệt. Không có network hop, không có control plane phụ, không có bề mặt vận hành mới chỉ để giữ an toàn cho tiến trình workflow. Đối với nhiều hệ thống, một file cơ sở dữ liệu cục bộ chính là mức độ máy móc phù hợp.
Litestream giúp di động hóa
Mối quan tâm rõ ràng là phải làm gì với những file SQLite đó khi các thử nghiệm bắt đầu tích lũy. Đó là lúc Litestream phát huy tác dụng. Nó có thể stream các thay đổi SQLite một cách bất đồng bộ lên S3-compatible object storage. Điều này mang đến một cách đơn giản để giữ trạng thái làm việc gần runtime trong khi vẫn copy database ra để backup, di chuyển và kiểm tra.
Tuy nhiên, có một điểm yếu: replication của Litestream là bất đồng bộ. Nếu volume SQLite biến mất trước khi các ghi mới nhất được copy, quá trình restore có thể thiếu chúng. Điều này ổn với nhiều workflow AI và thử nghiệm, nhưng không tương đương với một cơ sở dữ liệu chia sẻ có tính khả dụng cao.
Dù vậy, mô hình vận hành vẫn hữu ích: chạy một server Obelisk với database SQLite, backup bằng Litestream, và để một observer kéo các database thú vị khi cần. Cùng một file có thể được dùng cho local replay, debug và hiểu những gì agent thực sự đã làm.
Tại sao điều này hiệu quả với AI agents
Điều này đặc biệt hấp dẫn đối với AI agents và các workflow do AI tạo ra. Những hệ thống này thường bùng nổ, thử nghiệm và dễ suy luận hơn khi mỗi agent hoặc tenant có một đơn vị trạng thái nhỏ tự chứa. Một đội tàu các server nhỏ trong micro VM hoặc container, mỗi cái có database SQLite riêng và backup object storage, thường phù hợp hơn một hệ thống chia sẻ lớn luôn bật. Nó đơn giản hơn, rẻ hơn và cách ly lỗi tốt hơn.
Khi nào nên dùng Postgres
SQLite không phải là câu trả lời cho mọi hình thức triển khai. Obelisk cũng hỗ trợ Postgres, và đó là lựa chọn đúng khi bạn cần tính khả dụng cao hơn, khả năng mở rộng chia sẻ rộng hơn, hoặc các thuộc tính triển khai khác được phục vụ tốt hơn bởi một database mạng. Nó cũng phù hợp hơn khi asynchronous replication lên object storage không phải là mô hình bền vững bạn muốn.
Nhiều hệ thống workflow không cần điều đó ngay từ ngày đầu và không nên bắt đầu với nhiều hạ tầng hơn mức trạng thái của chúng thực sự yêu cầu. Trong một tập hợp lớn các trường hợp, một database SQLite cục bộ cộng với backup Litestream lên S3 là đủ. Thêm các worker rẻ tiền xung quanh và bạn có một hệ thống bền vững với rất ít hạ tầng. Đối với thế giới AI agents, đó có thể là mặc định hợp lý nhất.
Nguồn: Hacker News - https://obeli.sk/blog/sqlite-is-all-you-need-for-durable-workflows/
