A fantasy-sports platform faces a synchronised traffic spike in the minutes before a major match starts. Workers are saturated. What should be shed, in what order, and what must never be shed?

Why shedding beats scaling here

The spike is minutes long and arrives faster than any autoscaler can respond, because the trigger is a scheduled real-world event and the ramp is near-vertical. Instances take a minute or more to become useful. By the time capacity arrives, the deadline has passed.

So the design must be pre-provisioned for the known peak plus a shedding policy for the unknown excess, and the shedding policy is the part teams neglect because it only matters for ten minutes a week.

The priority order

Never shed: - Contest entry and the wallet debit that accompanies it. This is the revenue event and the deadline is hard — entries close at match start and a rejected entry cannot be retried later. - Team submission and edits before lock. Same deadline property. - Anything already accepted: an entry that took money must complete.

Shed early and aggressively: - Leaderboards and rank displays. Serve a cached snapshot with a visible timestamp. - Notification fan-out. Queue it; nobody needs it during the spike. - Recommendations, banners, personalised content, social feeds. - Analytics and event ingestion, which can be buffered. - Historical statistics and past-contest views.

Degrade rather than shed: - Contest listings: serve a cached list, refreshed less often, rather than a live one. - Balance display: last known value with a timestamp, while the authoritative balance check at entry time stays strongly consistent.

The mechanics that make it work

• Shed at the edge, cheaply, before a request consumes a worker, a connection or a database round trip. Shedding after the work is done costs the same as serving.
• Priority must be a property of the request, tagged at ingress, not inferred deep in a service that has already paid most of the cost.
• Return a fast, explicit rejection with a retry hint. A slow rejection is worse than a fast one because the client's timeout expires and it retries, multiplying load exactly when you are shedding it.
• Rehearse it. A shedding path that has never run in production will not work the first time it is needed, and the first time it is needed is the worst moment to discover that.