First establish that you are not going to serve it
Do the capacity arithmetic out loud, because the answer changes shape once you have. Suppose you serve 5,000 requests a second at 60 per cent CPU. Your ceiling before latency collapses is somewhere near 8,000. A hundred times normal is 500,000 a second.
So you will serve, at best, 1.6 per cent of what is arriving. No configuration changes that in ten minutes. Autoscaling does not help either: even if the group scales, your database connection count, your third-party payment provider's rate limit and your own warm-up time all cap out long before 60x.
That reframing is the answer an interviewer is waiting for. You are not designing a way to survive the traffic. You are choosing which 98 per cent of it loses. A system that has not chosen will make the choice at random, which means the customer holding a full cart is exactly as likely to be dropped as a scripted request that was never going to buy anything.
This assumes you already know the volume is not organic. Whether a surge is an attack or a promotion is a separate problem with separate signals. Here the volume is settled, and triage is all that is left.
Shed cheapest and least valuable first
The ordering below is the substance of a good answer, and each step is chosen because it costs you less than the step after it.
Absorb what your application never has to see. Volumetric traffic at the network layer belongs upstream, on anycast capacity that is measured in terabits rather than in your instance count. SYN cookies handle spoofed connection floods at the edge. A packet that never reaches your load balancer needs no triage, so this tier is free in the sense that matters.
Serve cacheable requests from the edge. A request answered by a cache costs you nothing and helps genuine readers at the same time. A flood is also the moment to widen what counts as cacheable: a homepage that normally personalises a header can serve a generic one, and a product page can serve a price that is thirty seconds stale. Both are real degradations. Both beat being unavailable.
Shed by cost per request, not by URL. A search query that fans out to five services and a static product lookup are not comparable, and the flood will be aimed at whichever is most expensive. So you need your per-endpoint cost before the incident. Nobody measures it during one.
Refuse new sessions before sessions already in flight. A user who is three steps into checkout has already consumed database writes, an inventory hold, and a payment-provider round trip. Dropping them wastes work you have paid for and loses revenue you nearly had. A homepage arrival has cost you nothing yet. Admission control belongs at the front door, and it must be positional: bias against entry, not against progress.
Keep authenticated sessions with history last. A logged-in account with a purchase two weeks ago is the least likely thing in the traffic to be part of an attack and the most likely to be worth money.
The priority signal has to be cheap to check
The ordering above is useless if evaluating it costs a database query, because you are overloaded and the database is the thing you are protecting. Whatever decides a request's tier has to be readable at the edge with no lookup at all.
The usual shape is a signed cookie or token issued at login and at cart creation, carrying a tier and an expiry. The edge verifies a signature, reads a small integer, and admits or refuses. No state, no round trip.
tier=2 exp=1786800000 sig=...
The consequence is that this token has to exist before the incident, issued on a normal day, as part of the ordinary login path. A priority scheme designed during an outage cannot be applied. The traffic already in flight does not carry the marker it needs.
Rejecting fast beats queueing slowly
A queue feels kinder than a refusal and behaves worse. A request that sits for thirty seconds and then times out has consumed a connection, a thread or an event-loop slot, and some memory for its whole wait, and delivered nothing. Then the client that gave up tries again. You paid for that request twice.
Put a number on that. If each of 500,000 arriving clients a second retries three times on failure, you have invited 1.5 million a second, and the flood is now largely your own doing. A retry storm is the most common way a survivable overload becomes an outage, and it is entirely under your control: bounded queues that reject when full, a refusal that carries a machine-readable retry hint, and clients that honour it with exponential backoff and jitter. Your own mobile app and internal services are clients too, and they are the ones you can fix.
Where you cannot tell a real client from a scripted one, prefer a challenge over a refusal. Work that a browser performs without the user noticing is expensive to perform half a million times a second, which shifts the economics without deciding anybody is guilty. The limit of that technique is worth naming: it breaks every legitimate non-browser client you have, including your own API consumers and your mobile app, so they need a bypass, and that bypass is the next thing an attacker will aim at.
What separates a strong answer here
Two things, and both are omissions rather than errors.
The first is ranking by business importance instead of by unit cost. Candidates say "protect checkout" and stop. It sounds right and it is incomplete, because checkout is also the most expensive path you own. Protecting it means shedding elsewhere hard enough to leave it headroom, and that is a different plan from labelling it important.
The second is forgetting that shedding must be measured while it runs. You need to know how many requests you refused, in which tier, and what fraction of refusals were customers, because the number you will be asked for afterwards is not how much traffic you absorbed. It is how many real people you turned away, and whether you turned away the right ones.
At 100x you are not choosing how to serve the traffic, you are choosing who loses. Make that choice in advance, encode it in something the edge can read without a lookup, and refuse fast enough that the refused client does not come back three more times.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).