How We Made QStash And Upstash Workflow Reliable At Scale

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

Bài của nhà cung cấp; mọi nhận định là theo Upstash. Không có số liệu.

Bối cảnh

• QStash (message queue/lịch gọi HTTP) và Upstash Workflow gọi endpoint của khách.
• Thiết kế từ đầu để không phụ thuộc một máy lớn mãi: storage là một pool database Upstash Redis, tài nguyên và task của khách rải qua các DB, thêm DB khi cần thay vì migrate sang node to hơn; compute là cụm process QStash đối xứng, process nào cũng làm được mọi việc, chết một thì process khác phát hiện và làm tiếp; tăng tải thì thêm process.
• Theo Upstash, nền đó đủ trong một thời gian dài; vấn đề xuất hiện khi hành vi của khách phức tạp hơn chứ không chỉ khi tải lớn hơn.

Ba vấn đề và cách xử lý

1. Traffic dồn kèm payload lớn: không phải tải đều (autoscaling kịp phản ứng) mà là bộ nhớ tăng vọt trong khoảng rất ngắn, process tiến tới OOM nhanh hơn tốc độ thêm máy, rồi thành crash loop.
   • Một goroutine theo dõi heap; vượt ngưỡng (theo memory limit của máy, chừa phần cho socket buffer, file cache, runtime) thì bật trạng thái nguy cấp. Các đường fetch nặng (worker tìm task, poller đọc queue từ Redis, pipeline xuất log của khách) dừng trước lần fetch tiếp cho tới khi bộ nhớ xuống dưới ngưỡng.
   • Backpressure cục bộ và tạm thời; nhưng làm chậm việc của khách vẫn là chế độ suy giảm, nên vào trạng thái này là gọi người trực để thêm năng lực, không để "an toàn mà im lặng".
2. Endpoint của khách ngừng trả lời (không fail nhanh, treo hàng giờ, hàng ngày): retry mạnh tay không giúp gì mà chiếm bộ nhớ, queue, thời gian xử lý của mọi người.
   • HostBlocker: endpoint timeout thì host vào trạng thái chặn tạm thời, chờ rồi mới thử lại; timeout tiếp thì chờ lâu hơn. Có nút để admin đưa host về ngay khi khách sửa xong.
   • Theo Upstash: độ tin cậy không chỉ là retry mà là cô lập lỗi.
3. Thay hệ con trước khi thành sự cố:
   • viết lại flow control để hành xử dự đoán được dưới tải;
   • log từ SQLite sang Elasticsearch: ghi kép nhiều tuần, khi hệ mới đủ lịch sử bằng cửa sổ lưu giữ khách mong đợi thì chuyển dần đường đọc, giữ hệ cũ làm dự phòng thêm một thời gian.

Bài học cho SWE

• Ngưỡng bộ nhớ làm tín hiệu backpressure cho worker kéo việc: dừng kéo khi gần OOM; và phải báo người, vì suy giảm im lặng vẫn là sự cố (Load shedding, rate limit và backpressure).
• Giao tới endpoint bên ngoài cần chặn theo host với thời gian chờ tăng dần, cùng bài toán "recipient chậm" của Atlassian 2026 (Atlassian 2026, Event-driven, message queue và Kafka).
• Migration kho log: ghi kép tới khi kho mới có đủ lịch sử bằng retention rồi mới chuyển đọc (Migration không downtime).

Liên quan

• Load shedding, rate limit và backpressure
• Event-driven, message queue và Kafka
• Migration không downtime
• Cùng công ty: Upstash 2026