Load Shedding
Load shedding rejects some work as a system nears capacity. This protects useful work from extreme delay or a full crash.
capacity signal + priority + admission gate -> admit | reject early + retry guidance1,000✓safe capacity1,000→admitted240×rejected earlycapacity signal + priority + admission gate -> admit | reject early + retry guidanceSREAnother example
A service can handle 1,000 requests each second. Demand reaches 1,240. It keeps important checkout traffic and quickly rejects 240 requests.
Main parts
- 01Capacity signal
- 02Admission threshold
- 03Request priority
- 04Fast rejection
- 05Caller guidance
- 06Recovery threshold
Use it when
Use it after measuring safe capacity and request priority. Reject cheaply near the edge and give callers a clear retry signal.
Do not use it when
Do not silently drop accepted durable work. Do not wait until the server is already stuck. Coordinate retries to prevent another spike.
Name used in code
capacity signal + priority + admission gate -> admit | reject early + retry guidance Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Load Shedding for this system while keeping data correct, secure, and easy to operate. User context: A service can handle 1,000 requests each second. Demand reaches 1,240. It keeps important checkout traffic and quickly rejects 240 requests. Technical concept or control: Load Shedding. Why it fits: Use it after measuring safe capacity and request priority. Reject cheaply near the edge and give callers a clear retry signal. Do not use it when: Do not silently drop accepted durable work. Do not wait until the server is already stuck. Coordinate retries to prevent another spike. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Load Shedding. Definition: Load shedding rejects some work as a system nears capacity. This protects useful work from extreme delay or a full crash. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.