Our Migration to FoundationDB, Part 1

Inngest · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Phần 1 (vì sao và chọn thế nào). Phần 2 (thiết kế shard): Inngest 2026. Phần 3 (rollout, benchmark) chưa đăng khi wiki đọc (URL trả 404).

Bối cảnh

Queue của Inngest quyết định job nào chạy tiếp, cho account nào, trên executor nào; mọi lần chạy function đều đi qua nó, và nó phải giữ công bằng giữa các tenant. Hiện chạy nhiều shard queue tách theo bậc giá (free, self-serve, enterprise) cộng shard nội bộ (cron, debounce).
Vấn đề với Valkey (Redis đổi giấy phép, chạy trong RAM):
- hết RAM là cả cụm sập, không chỉ tenant gây ra; khi đó mọi function dừng và hệ phụ thuộc cũng ùn theo;
- độ bền chỉ tốt bằng cấu hình replication và persistence; mất điện hay hỏng node sai chỗ có thể mất dữ liệu, nghĩa là queue "quên" một lần chạy;
- khôi phục phụ thuộc vào việc đưa một cụm đơn luồng có trạng thái về nhất quán, không phải tốc độ failover;
- đơn luồng nên mỗi lần chỉ xem được một phần account, function, item; không bảo đảm được công bằng, và mỗi tính năng thêm (công bằng, quan sát) lại làm chậm thêm.

Đã thử trước khi đổi DB (khoảng 2 năm)

Shard ngang: nhóm executor theo bậc giá, lease shard, autoscale theo operator. Nhưng gán shard vẫn tĩnh và làm tay; thêm năng lực là dựng tay cụm Valkey mới.
Constraint API: tách việc thực thi giới hạn (concurrency, throttle) ra một service riêng.
Key queue v1, v2: công bằng theo key để tenant ồn không bỏ đói tenant khác. Cả hai đều vướng hiệu năng của DB bên dưới.
Theo Inngest: liên tục đụng cùng một bức tường từ nhiều hướng, đến lúc đó là bài toán storage engine, không còn là bài toán queue.

Tiêu chí, rồi mới chọn

Đúng trong điều kiện thật: công bằng nhiều tầng, thứ tự chặt khi cần;
scale ngang hoàn toàn (thêm đĩa và compute, không dựng shard tay);
cách ly noisy neighbor;
chi phí vận hành thấp;
rollout an toàn, quay lui được giữa chừng.

Quy trình chung họ nêu: hiểu yêu cầu và nguồn gốc của chúng, lấy số liệu production hiện tại và quy mô dự kiến, rồi mới so giải pháp; loại thứ không giải đúng vấn đề hoặc làm quá tay so với thời gian dùng dự kiến.

Vì sao FoundationDB

ACID và ghi xuống đĩa khi commit nên giải luôn khoảng trống về độ bền;
dữ liệu trên đĩa nên backlog 10 hay 10 triệu item không còn là vấn đề RAM; tenant bão hoà không kéo sập cả cụm;
đa luồng, scale ngang bằng cách thêm phần cứng;
đường đọc tách khỏi đường ghi, nên đọc cho quan sát không tranh với ghi;
đã được kiểm chứng ở quy mô lớn hơn nhiều (Apple CloudKit, metadata của Snowflake). Họ tham khảo paper CloudKit, QuiCK.
Đánh đổi: mô hình vận hành khác hẳn họ Redis, có đường cong học riêng.

Kế hoạch

Mỗi bậc giá một cụm FDB, cộng một cụm cho metadata và định tuyến. Account gom vào logical shard được gán tự động. Enterprise có thể có shard riêng mà không phải dựng cụm vật lý.
Rollout theo bậc: Hobby trước, rồi self-serve, enterprise cuối. Trong mỗi bậc mở cho từng nhóm account, theo dõi rồi mới mở rộng. Lúc viết đang ở giai đoạn benchmark và test rollout trên account nội bộ.

Bài học cho SWE

Biết khi nào đã đụng trần của một kho dữ liệu: nhiều lần tối ưu đều vướng cùng một gốc thì đó là lúc đổi engine (Chọn database theo workload).
Với hệ multi-tenant, "một tenant làm sập cả cụm" (OOM) là lỗi thiết kế cần loại bỏ (Hot partition và thundering herd).
Viết tiêu chí trước khi so giải pháp, và coi "quay lui được giữa rollout" là tiêu chí ngang hiệu năng.
Rollout bắt đầu từ khách ít rủi ro nhất (gói miễn phí).