Here is the whole problem in one picture. The box on the right is the server; it picks up a request, works on it, and only then reaches for the next. There is no room to wait yet, so anything that arrives while the server is busy is turned away on the spot. Push the traffic up and watch requests bounce off a server that simply cannot be in two places at once.

Add a queue and the picture changes. Now a request that finds the server busy lines up instead of being thrown away, and a short burst of traffic gets soaked up rather than lost. But a queue only has so many slots. Under steady overload it fills to the brim, and once it is full we are back to turning requests away. Drag the queue size up and watch the dropped slice shrink, then push the traffic past what the server can clear and watch it come back.

So make the queue enormous and stop dropping things? Not quite. A request that has been sitting in line for ten seconds is often worthless by the time it is picked up: the person behind it has refreshed, the caller upstream has already given up. That is a timeout, and a giant queue just trades dropped requests for a pile of stale ones that waited forever for nothing. Lower the timeout and watch the amber slice of give-ups grow.

FIFO makes this worse than it needs to be. First-in-first-out serves the oldest request first, which is exactly the one most likely to have already timed out. You spend the server on requests nobody is waiting for anymore.

Flip it around. LIFO serves the most recent arrival first, on the bet that a fresh request is more likely to still matter. When traffic is bursty this is a real win: the typical wait drops, because whoever just showed up gets served while the backlog waits. The catch is in the tail. Toggle between FIFO and LIFO and watch the latency chart: LIFO's median gets better, but a few unlucky requests at the bottom of the pile can sit there forever.

Not every request is equal. A checkout is worth more than a preloading thumbnail; a health check is worth more than an analytics ping. A priority queue lets the important ones (the ones with a bright ring below) cut to the front of the line no matter when they arrived. Watch them jump the queue while the ordinary requests shuffle along behind.

Cutting the line helps once a request is already waiting, but under a real flood even the priority requests get stuck behind a wall of low-value ones clogging the queue. The fix is to stop letting the junk in. RED (Random Early Detection) starts turning away low-priority requests before the queue is full, gambling that shedding some of them now keeps room for the ones that matter. Switch between plain Priority and Priority + RED under this flood and watch the important requests keep flowing instead of drowning.

Now it is a sandbox. Switch strategies mid-flood, grow and shrink the queue, drop the timeout, and push the traffic past what one server can possibly handle. There is no strategy that wins everywhere; each one decides which failure it would rather have.