One of your three availability zones fails and the surviving capacity can serve only about 70% of peak traffic. Would you let all users experience a slow, partly broken service, or deliberately serve 70% of them fully and reject the rest? How would you decide, and who has to agree to that beforehand?

## The choice, stated honestly A capacity shortfall forces a distribution decision that most teams have never made explicitly: with 70% of the capacity and 100% of the demand, do you give everybody 70% of a service, or 70% of people 100% of a service? The instinct — and the default behaviour of a system with no shedding at all — is the first. It feels fairer, and it avoids the uncomfortable act of turning users away. It is usually the worse choice, and being able to say why is the point of the question. ## Why uniform degradation costs more than it saves **Incomplete work is repeated work.** A user whose page half-loaded reloads it. A user whose checkout failed at the payment step tries again, often from the start. A partially served request has consumed capacity and produced nothing durable, and it usually comes back. A cleanly rejected user with an honest error message is far more likely to wait or leave. So uniform degradation generates additional offered load at the exact moment there is none available — the same self-amplifying dynamic that turns overload into collapse. **Nothing completes end to end.** Product value lives in journeys, not requests. If every step of a five-step flow has a 30% chance of failing, roughly 17% of journeys complete. Rejecting 30% of *users* and serving the rest cleanly completes about 70% of journeys. The same capacity, four times the delivered outcome. **Diagnosis becomes impossible.** Universal partial failure means every dashboard is amber and every service looks slightly ill, so the on-call responder cannot tell which component is the constraint. A clean split — a defined share served correctly, the rest rejected at the edge with a known reason — leaves the telemetry legible. The honest counter-case exists and you should name it: where partial results are genuinely useful and stateless — a search returning fewer results, a feed with fewer items, video at a lower bitrate — degrading everyone can beat excluding anyone. The rule of thumb is that degradation wins when a partial answer is still a usable answer, and shedding wins when the product is a multi-step transaction. ## Choosing the unit of shedding This is where designs quietly fail. Shedding per request produces the worst of both worlds: each user experiences a random 30% of their requests failing, which is uniform degradation wearing a load-shedding costume. Shed on a stable key — a hash of the user or session identifier — so that a given user is either in or out for the duration, and the ones who are in complete their journeys. That immediately raises fairness, which is a policy question rather than a technical one. Consistent hashing means the same unlucky users are excluded for the entire incident; rotating the excluded set spreads the pain but breaks journeys mid-flight. Common resolutions: rotate slowly, at a period longer than a typical session; never shed a session that is already inside a transactional flow; and always let already-authenticated, in-progress journeys drain. ## Where the ranking comes from The ordering is a business decision, not an engineering one, and it must be written down before it is needed. A workable degradation ladder names, in order: the flows protected to the last drop of capacity (usually payment, safety, regulatory, and anything that would corrupt state if interrupted); the features turned off first (recommendations, personalisation, analytics beacons, non-essential enrichment); how customer tiers rank against each other, informed by contractual commitments; and how internal traffic — batch jobs, backfills, cache warming — is stopped outright before any user traffic is touched. The stakeholders who must sign it are product (which features may go dark), support (what users are told, and what the status page says), and legal or commercial (where contractual commitments constrain who may be shed). Engineering owns the mechanism; it does not own the ranking, and a plan engineering wrote alone will be renegotiated live during the incident, which is the worst possible time. ## What makes it a real control Three things, all of which are usually missing: **Pre-authorisation.** On-call must be able to invoke the ladder without an approval chain. A lever that requires a vice-president at 3am is not a lever. **Rehearsal.** A shed path exercised for the first time during an incident will not work — the flag is stale, the config path is broken, the fallback page 500s. It needs to be pulled deliberately, in production, on a schedule. **Observability of the shed.** You must be able to see how much is being shed and who is being shed, or you will not know when to restore, and you will not notice when the mechanism silently stops shedding. ## The interview point The candidate to hire is the one who reaches for the deterministic split, justifies it with the retry dynamics rather than a slogan about fairness, picks the session as the unit, and then spends most of the answer on the part that is not technical at all: who agreed to this ranking, when, and whether anyone has ever pulled the lever in anger. Sizing headroom so the zone loss is absorbed in the first place is the preventive discipline, but this question assumes it was insufficient — which, on the day of a real regional event, it frequently is.