Backpressure: làm chậm producer khi consumer không kịp — đẹp khi bạn control cả hai đầu.
Internet user / mobile app: bạn không bảo họ “chậm lại”. Khi inventory đầy, latency đã vỡ — load shedding = từ chối có chủ đích để phần còn lại còn dùng được.
Vì sao nhận thêm là hại
- Queue vô hạn: mọi request chậm — “công bằng” cùng khổ.
- Retry client đập thêm — storm.
- Hết budget hàng loạt: work mồ côi nếu không cancel.
Shed sớm: một phần 503 nhanh; phần còn lại p99 chấp nhận được.
Khi nào shed
- In-flight / queue depth / heap / CPU / event loop lag quá ngưỡng.
- Dependency breaker đỏ + không có fallback hữu ích.
- Bulkhead khoang đầy — đừng tràn sang khoang khác.
Cách shed
503 Service Unavailable + Retry-After
429 khi đúng là quota user (rate limit)
Từ chối low-priority / batch trước (priority queue)
Shed ở edge (gateway) — đừng để vào app rồi mới chết
Fail-fast: đừng giữ connection “cho lịch sự”// Ý edge/app
if (inflight >= MAX || eventLoopLag > THRESH) {
res.setHeader('Retry-After', '2')
return res.status(503).json({ error: 'overloaded' })
}Khi không shed
- Còn headroom — đừng 503 “phòng hờ” giết conversion.
- Path critical đã bulkhead riêng: shed nice-to-have trước, không cắt auth/pay sớm hơn policy.
- Client không retry được và không có UX rõ — ưu tiên degrade (cached/stale) hơn hard fail nếu product cho phép.
Shed vs rate limit vs pool
- Rate / pool: trần bình thường.
- Shed: phản ứng quá tải — có thể aggressive hơn quota ngày thường.
Product / SLO
Shed làm tăng error rate có kiểm soát. Nói với product: “từ chối 5% còn hơn 100% request 30s”. Liên quan error budget.
Một câu để nhớ
Giữ 80% request tốt còn hơn 100% request cùng chậm chết.
Shed là van an toàn — không phải bất lịch sự.