Why does a bits-per-second DDoS threshold never fire when an attacker's 400 search requests a minute exhaust the database pool behind a public API?

## The two numbers that never meet A volumetric mitigation device sits in the path and makes decisions from quantities it can derive from packets alone: ingress bits per second, packets per second, new connections per second, connections in each TCP state, fragment ratios, per-source packet counts. Those are the right units for a flood. A reflected amplification attack or a packet flood is *defined* by moving more bits or more packets than the path can carry, so a threshold on bits or packets is a direct measurement of the damage. A low-volume expensive-request attack inverts that relationship. The attacker's whole strategy is to find an ask that is cheap for him to send and costly for you to answer, then to send just enough of them. The asymmetry does the work; the volume does not. A single well-formed search that scans an entire table, an export with no upper bound on its date range, a report that joins across a shared analytics store - each is a few hundred bytes on the wire and tens of seconds of a database worker on the other end. ## Why no threshold you could set would catch it Suppose the service normally takes 300 requests a minute and the attack adds 400. On the border counters that is a change of a few megabits per second on a link provisioned for gigabits. To fire on it, you would have to set a threshold below your own ordinary Tuesday afternoon, and far below the traffic of any legitimate launch, marketing email or client retry. The device would then mitigate your customers routinely and still not be measuring the thing that is hurting you: it would be firing on a proxy that correlates with load only by accident. This is the important generalisation, and it is the one interviewers are testing. **The measurement carries no information about the property you care about.** Increasing resolution, sampling more often, or adding more counters of the same kind does not help, because a request's cost to answer is not a function of its size on the wire. Two requests of identical length, identical protocol and identical source can differ by four orders of magnitude in what they cost to serve. ## What does move during the attack It is worth knowing which numbers *do* change, because that is how you confirm the diagnosis: | Where you look | What you see | | --- | --- | | Border bits/packets/connections per second | Flat, far below any threshold | | Mitigation event log | Zero events, and correctly so | | Concurrent established connections | Drifting up as responses stall | | Service request count | Barely changed | | Service p99 latency | Enormous | | Shared database pool | Fully busy, deep queue | | Client-side result | Timeouts, resets, an unusable service | The border-side symptoms - longer-lived connections, more concurrent sockets, eventual resets - are the *service failing* observed from the wire. They arrive after the damage, not before it, and they look identical to a slow backend for any other reason. They are not a volumetric signal. ## The direction of the claim Be careful about what zero mitigations proves. It proves that no counter the device meters crossed a configured threshold. It does not prove that no attack occurred, that no hostile traffic arrived, or that the estate is healthy. The absence of a detection is a statement about the detector's inputs. On this class of attack the detector was never given an input that could carry the evidence, so its silence is guaranteed in advance and tells you nothing at all about the adversary. ## What the defender is paying Two things, and naming both is what separates a real answer from a definition. First, the capacity: the shared database pool, held and funded for legitimate peak, is consumed by requests that cost the attacker almost nothing to issue - the asymmetry is the whole attack. Second, the visibility: the organisation is paying for and reporting on a mitigation control that has a class of outage it can never see, and unless someone says so out loud, availability commitments get written on the assumption that the control covers it. ## The answer an interviewer wants State the unit mismatch in one sentence - the threshold is a traffic rate, the damage is work per request - and then say where the control has to live instead: at a component that can see the request and know what it will cost before the expensive work begins. That is a different vantage from the border, and it comes with its own bill.