Tránh bẫy Thác nước bất đồng bộ (Async Waterfalls)

Tóm tắt nhanh (TL;DR)

Hãy khởi chạy các tác vụ bất đồng bộ độc lập càng sớm càng tốt. Chỉ sử dụng await khi công việc phía sau thực sự phụ thuộc vào kết quả của tác vụ phía trước, hoặc khi thứ tự thực thi có chủ đích nghiệp vụ rõ ràng.

Từ khóa await tạm dừng hàm async bao quanh nó cho đến khi Promise được giải quyết; nó không hề chặn Main Thread của JavaScript. Một "thác nước bất đồng bộ" (async waterfall) hình thành khi mã nguồn chờ đợi một thao tác hoàn tất trước khi kích hoạt một thao tác khác vốn có thể chạy hoàn toàn song hành và độc lập.

Đừng thay thế một cách máy móc mọi chuỗi await tuần tự bằng Promise.all(). Trước tiên, hãy phân tích đồ thị phụ thuộc dữ liệu (dependency graph), cho phép các tác vụ độc lập chạy gối đầu nhau, và luôn giới hạn mức độ đồng thời (bounded concurrency) khi chịu áp lực tài nguyên hệ thống.

Mô hình tư duy (Mental Model)

Hãy bắt đầu với một kịch bản thời gian biểu cụ thể. Giả sử hệ thống cần thực hiện ba tác vụ độc lập lần lượt mất 800ms, 400ms, và 300ms.

Nếu mỗi tác vụ chỉ khởi động sau khi tác vụ trước kết thúc hoàn toàn:

Tác vụ A: 0 ───────────── 800
Tác vụ B:                 800 ───── 1200
Tác vụ C:                            1200 ─── 1500

Tổng thời gian thực thi là 800 + 400 + 300 = 1500ms.

Nếu cả ba tác vụ có thể khởi động ngay lập tức tại thời điểm ban đầu:

Tác vụ A: 0 ───────────── 800
Tác vụ B: 0 ───── 400
Tác vụ C: 0 ─── 300

Tổng thời gian thực thi chỉ bằng tác vụ lâu nhất: max(800, 400, 300) = 800ms. Khoảng thời gian chờ đợi đã gối đầu lên nhau, tiết kiệm được tới 700ms.

🖼️ [Illustration Placeholder: Đối chiếu Waterfall và Chạy đồng thời trên DevTools Network]
Mô tả hình minh họa: So sánh trực quan trên bảng Network của DevTools giữa hai đồ thị thực thi:

• Tuần tự bậc thang (Waterfall): Request A (800ms) -> Request B (400ms) -> Request C (300ms) tạo thành bậc thang nối tiếp tổng cộng 1500ms.
• Đồng thời (Concurrent): Cả ba Request A, B, C cùng xuất phát tại t = 0ms; hoàn tất khi request dài nhất (A, 800ms) kết thúc.

Câu hỏi cốt lõi khi thiết kế:

Cần thông tin gì tồn tại trước khi thao tác này có thể bắt đầu?

Nếu câu trả lời là "không cần dữ liệu nào từ thao tác trước", thao tác đó hoàn toàn có thể được kích hoạt sớm hơn.

Thử nghiệm thực tế: Async Waterfall Lab

Tự điều chỉnh thời lượng của 3 tác vụ để quan sát trực quan sự chênh lệch thời gian giữa hai mô hình:

Nhận diện nguyên nhân gây ra Thác nước

Mã nguồn tuần tự rất dễ đọc và trực quan, do đó thác nước vô tình xuất hiện trông rất bình thường:

const user = await getUser(id);
const organization = await getOrganization(user.organizationId);
const flags = await getFeatureFlags(id);
const recommendations = await getRecommendations(id);

Trong ví dụ trên:

• getOrganization bắt buộc phải chờ getUser vì nó cần user.organizationId (phụ thuộc thực tế).
• Nhưng getFeatureFlags(id) và getRecommendations(id) chỉ cần id ban đầu; chúng hoàn toàn không cần user hay organization! Việc bắt chúng đứng chờ là sự lãng phí thời gian không đáng có.

Giải pháp tối ưu là chạy gối đầu các tác vụ độc lập:

const flagsPromise = getFeatureFlags(id);
const recommendationsPromise = getRecommendations(id);

const user = await getUser(id);
const organization = await getOrganization(user.organizationId);

const [flags, recommendations] = await Promise.all([
  flagsPromise,
  recommendationsPromise,
]);

Ở đây, chuỗi user → organization vẫn diễn ra tuần tự đúng nghiệp vụ, trong khi hai tác vụ độc lập kia đã hoàn thành xong từ trước.

🖼️ [Illustration Placeholder: Đồ thị DAG và Đường găng (Critical Path)]
Mô tả hình minh họa: Sơ đồ luồng DAG:

• Nhánh phụ thuộc: getUser(id) (500ms) -> getOrganization(user.orgId) (400ms) tạo thành Đường găng chính (900ms).
• Nhánh độc lập: getFeatureFlags(id) (300ms) và getRecommendations(id) (700ms) khởi động song song tại t = 0ms và hoàn thành trước khi đường găng kết thúc.

Promise.all() là công cụ, không phải quy tắc vạn năng

Promise.all(iterable) trả về một Promise hoàn thành khi tất cả các Promise con đều hoàn thành. Kết quả trả về giữ nguyên thứ tự truyền vào ban đầu.

Tuy nhiên, cần đặc biệt lưu ý: khi một Promise con bị reject, Promise.all() lập tức bị reject mà không hề tự động hủy bỏ (cancel) các tác vụ con khác đã được khởi chạy! Các thao tác đó vẫn tiếp tục chạy ngầm trong nền trừ khi API bên dưới hỗ trợ cơ chế hủy (như AbortSignal) và bạn chủ động kích hoạt nó.

Cân nhắc trong môi trường Production

Tình huống thực tế: Cơn bão Fan-out đánh sập dịch vụ nội bộ

Một dịch vụ báo cáo phân tích cần truy xuất lịch sử giao dịch cho 2,000 thành viên tích cực. Một lập trình viên nhận thấy vòng lặp for...await chạy quá chậm nên đã thay thế bằng:

await Promise.all(members.map(fetchHistory));

Ở môi trường kiểm thử với 10 người dùng, đoạn code chạy cực nhanh trong 45ms. Tuy nhiên khi triển khai lên production với 2,000 thành viên, nó lập tức kích hoạt 2,000 kết nối TCP đồng thời, làm tràn bộ đệm kết nối và kéo sập dịch vụ xác thực nội bộ với lỗi ECONNRESET, gây tê liệt hàng loạt dịch vụ phụ thuộc trong toàn công ty.

• Hậu quả: Hệ thống sập cục bộ trên diện rộng, tỷ lệ lỗi 5xx tăng đột biến trên production.
• Nguyên nhân cốt lõi: Lập trình viên nhầm lẫn giữa việc tối ưu hóa độ trễ của một request cá nhân với việc bảo toàn sức chịu tải đồng thời (throughput) của toàn hệ thống.
• Cách khắc phục chuẩn: Áp dụng cơ chế giới hạn mức độ đồng thời (Bounded Concurrency) thông qua Semaphore hoặc Worker Pool với limit = 10-20:

import pLimit from 'p-limit';
const limit = pLimit(15);

const results = await Promise.all(
  members.map(member => limit(() => fetchHistory(member)))
);

🖼️ [Illustration Placeholder: Cơ chế Semaphore giới hạn mức đồng thời (Bounded Concurrency)]
Mô tả hình minh họa: Sơ đồ kiểm soát Fan-out: 1,000 request được điều tiết qua Semaphore/Queue với concurrency = 5. Tại mỗi thời điểm chỉ có tối đa 5 kết nối đồng thời tác động vào cơ sở dữ liệu; các request còn lại xếp hàng đợi, giúp hệ thống vận hành ổn định và không bị quá tải.

Khi nào thực thi tuần tự là chính xác?

Thực thi tuần tự không phải là lỗi thiết kế. Hãy giữ nguyên tính tuần tự khi:

• Thao tác sau cần dữ liệu được sinh ra từ thao tác trước.
• Các thao tác ghi dữ liệu bắt buộc phải theo thứ tự thời gian định sẵn.
• Giao thức xử lý giao dịch (Transaction Protocol) yêu cầu các bước tuần tự.
• Hệ thống chủ động áp dụng cơ chế điều áp ngược (Backpressure).
• Thao tác phía sau chỉ nên chạy sau khi bước xác thực hoặc kiểm tra quyền phía trước thành công để tránh lãng phí chi phí tính toán.

Bài tập củng cố tư duy

Một request cần thực thi 4 thao tác sau:

Hãy xác định:

1. Những thao tác nào có thể chạy ngay?
2. Thao tác nào bắt buộc phải chờ?
3. Thời gian hoàn thành tối ưu nhất trong trường hợp lý tưởng là bao nhiêu?

Nguyên tắc cốt lõi dành cho Kỹ sư

Khi các thao tác bất đồng bộ độc lập với nhau, hãy khởi chạy chúng trước khi chờ đợi kết quả của thao tác khác. Giữ nguyên await tuần tự khi có phụ thuộc dữ liệu thực tế hoặc khi cần điều áp hệ thống. Không bao giờ đưa vào cơ chế đồng thời không giới hạn chỉ để giảm chút độ trễ, và không mặc định rằng Promise.all() bị lỗi sẽ tự động hủy các thao tác đang chạy ngầm.

Checklist kiểm tra khi tối ưu luồng bất đồng bộ:

• Phụ thuộc thật vs Phụ thuộc giả: Thao tác B có thực sự cần giá trị trả về của thao tác A không, hay chỉ ngẫu nhiên được viết nối tiếp nhau?
• Tác dụng phụ & Tính toàn vẹn: Có thao tác ghi dữ liệu hoặc sửa đổi trạng thái nào trở nên mất an toàn nếu chạy đồng thời không?
• Giới hạn Fan-out: Số lượng thao tác đồng thời có nguy cơ làm cạn kiệt socket mạng, pool kết nối cơ sở dữ liệu hay vượt ngưỡng rate limit không?
• Tận dụng thời gian gối đầu: Có công việc độc lập nào có thể kích hoạt sớm trong khi đường găng đang chạy không?
• Cơ chế hủy bỏ (Cancellation): Nếu một thao tác thất bại, các request còn lại có cần được hủy bỏ chủ động qua AbortSignal không?

Nguồn tham khảo chuẩn mực

• ECMAScript 2026 — Promise.all
• MDN — await
• MDN — Promise.all()
• MDN — Using promises