How Intelligent Load Shedding Prevents Cascading Failures in Tier-0 Systems

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

Bài phỏng vấn (chuỗi "Engineering Energizers") với VP Engineering của team Cloud Atlas. Mức kiến trúc, không có thuật toán hay số liệu đo; mọi nhận định là theo Salesforce.

Bối cảnh

• Cloud Atlas là kho dữ liệu định danh phân tán toàn cầu phía sau phần lớn việc xác thực của Salesforce: mỗi lần đăng nhập, mỗi lần kiểm token đều cần nó. Mục tiêu five nines (khoảng 5 phút downtime mỗi năm), dữ liệu trải nhiều region.
• Xác thực nằm ở "cửa trước": identity chậm thì service phụ thuộc chờ, request xếp hàng, upstream retry, retry lại thêm tải. Quá tải cục bộ thành lỗi dây chuyền.
• Workload tự động hoá và agent dồn theo đợt, khó đoán hơn nhiều so với người đăng nhập.
• Mô hình cũ: rate limit theo từng instance. Ổn khi hạ tầng tĩnh; khi bật autoscaling thì giới hạn của mỗi server lỗi thời mỗi lần thêm bớt instance, và mỗi server chỉ thấy tải của nó, không thấy tổng tải của khách trên cả fleet. Server bận từ chối request trong khi chỗ khác còn dư. Hệ multi-tenant nên một khách tăng đột biến ảnh hưởng khách khác (noisy neighbor). Chỉnh ngưỡng không chữa được, vì kiến trúc đang bảo vệ từng server chứ không bảo vệ cả service.

Thay đổi chính

• Loại rate limit tập trung: thêm một phụ thuộc vào đường request, có thể thành chính nút thắt nó định ngăn. Nguyên tắc: cơ chế bảo vệ không được thành một điểm hỏng mới.
• Load shedding thông minh: đo thời gian chờ trong queue làm tín hiệu áp lực sớm (latency tăng trước khi request lỗi), tự tăng throttle theo áp lực, bỏ việc ưu tiên thấp trước, giữ request tương tác như đăng nhập.
• Quota toàn cục không cần coordinator: các server đo mức dùng của từng khách và chia sẻ với nhau, mỗi server tự quyết throttle. Thích nghi khi fleet scale lên xuống, chặn một tenant ồn chiếm phần năng lực chung.

Nguyên tắc (theo Salesforce)

• Bảo vệ service, không phải từng server.
• Quan sát trước khi thực thi: đo xem cơ chế bảo vệ sẽ làm gì trước khi cho nó chạm traffic thật.
• Giảm chất lượng có chủ đích: làm chậm hoặc bỏ việc ít quan trọng tốt hơn để áp lực leo thang.
• Ưu tiên đơn giản hơn cấu hình: mỗi nút chỉnh thêm là một cơ hội hành vi bất ngờ.
• Phòng thủ nhiều lớp: load shedding, quota, công bằng, observability, autoscaling xử lý các kiểu lỗi khác nhau và phải phối hợp chứ không chống nhau.
• Ship có thể đảo ngược: bật dần, kiểm trên traffic thật, tắt nhanh được.

Bài học cho SWE

• Rate limit cục bộ cố định sai ngay khi fleet autoscale; cần giới hạn theo tổng tải của khách, chia sẻ giữa các node (Load shedding, rate limit và backpressure).
• Dùng queue time làm tín hiệu sớm thay vì đợi tỉ lệ lỗi (so với Canva 2026 dùng tỉ lệ lỗi, Airbnb 2026 dùng tỉ lệ latency).
• Ở dịch vụ dùng chung, retry của upstream là bộ khuếch đại chính (Hot partition và thundering herd).

Liên quan

• Load shedding, rate limit và backpressure
• Hot partition và thundering herd
• Multi-tenancy và cô lập tenant