Application layer floods exhaust a service by sending many expensive requests that look similar to ordinary user traffic.
The link can still have spare capacity while the application runs out of workers, database time, or memory.
How it works
A request that searches, logs in, or builds a heavy page costs more than a packet that only needs to be forwarded.
Attackers hide inside that cost by making the requests resemble real browsers, real accounts, or real shopping flows.
Defenders notice the pattern as rising errors, slow pages, and full queues even though the network graphs do not show a full pipe.
Useful responses reduce the cost of anonymous work, cache what can be cached, and add capacity with a plan, without publishing a recipe for the flood.
Concrete examples
- A search page becomes unusable because thousands of unique queries keep missing the cache and hitting the database.
- A login endpoint consumes all application workers while the bandwidth chart for the site stays far below its limit.
- A product catalog that builds images on demand stalls when repeated requests ask for combinations nobody has viewed before.
Protective measures
- Cache public pages and make expensive actions require a session that is costly to mint at scale.
- Limit repeated heavy requests per account and per address without blocking an entire city by accident.
- Watch application errors and queue depth beside bandwidth so this flood is not mistaken for a full link.
- Prepare a capacity and degradation plan so a surge sheds cheap features before the core service falls over.