Your service will exceed capacity by 30% during a known peak. Do you shed load or brown out, and how do you decide what goes first?

The decision

Brown out first; shed only if that is not enough. They are complementary rather than alternatives, and brownout is strictly less harmful when it is available.

Brownout makes every response cheaper — everyone stays served, everyone gets slightly less. Shedding rejects some requests entirely — some users get nothing.

For a read-heavy consumer surface, a 30% capacity gap is very often closable by brownout alone, because a large fraction of the work in a typical response is optional: personalisation, recommendations, enrichment, high-resolution assets, real-time counts.

What brownout looks like here

Concretely, in rough order of how much they save and how little they cost:

• Serve generic content instead of personalised (frequently the single largest saving).
• Reduce result set sizes — 10 items instead of 50.
• Serve from cache with an extended acceptable staleness.
• Omit optional enrichment fields.
• Lower image or asset resolution.
• Reduce analytics sampling rate.

What to shed, if you must

By an agreed business priority, classified at the edge and propagated:

1. Protected: checkout, payment, authentication, anything transactional.
2. Shed last: core browse and search.
3. Shed first: recommendations, personalisation panels, non-essential API consumers, batch and background work.

Two requirements people skip. The classification must arrive with the request and be carried through every hop, or downstream services cannot honour it. And the order must be signed off by the business in advance — engineering should not be deciding mid-incident that marketing personalisation is less important than search.

Preconditions that must exist before the peak

The optional work must be separable in the code, which is a design decision made months earlier. There must be a control signal to enable brownout — ideally automatic from queue depth or latency, with a manual override. And it must have been rehearsed, because a degradation path first exercised during the peak is a hypothesis.

What a strong answer adds

The counter-intuitive shedding rule: drop the requests that have already spent most of their deadline. Completing them helps nobody, and under overload that wasted capacity is exactly what you cannot spare. This requires deadline propagation, which is another reason it is worth the effort.