One tenant's export monopolises a shared analytics query pool — which denial-of-service controls answer this threat?

## Why this threat is different Most denial-of-service findings assume an outsider. This one does not. The actor is an authenticated tenant of a shared multi-tenant service, exercising a feature they are entitled to use, and the victims are the other tenants on the same infrastructure. Three consequences follow immediately, and a senior answer names all three. First, **identity controls contribute nothing**. Stronger authentication, mutual TLS, better session handling — none of it changes the outcome, because the caller is exactly who they claim to be and is authorised for the operation. The control has to shape consumption, not access. Second, **the offender is frequently honest**. The usual trigger is a scheduled export with a deeply nested grouping that a customer built themselves, or a report that got slower as their data grew. So the mitigation must be one you are willing to apply to a good customer: it has to degrade them fairly and predictably, with a clear error, not ban them. Third, **the threat belongs to the shared resource, not the endpoint**. Write it that way: *an authenticated tenant submits a query whose cost is unbounded relative to the request, occupying shared worker slots for minutes and denying interactive queries to every other tenant.* Naming the pool is what makes the mitigation obvious; naming the endpoint sends you off writing per-endpoint patches. ## Cost-based quotas beat count-based limits A request-per-second cap bounds arrivals. It says nothing about what an arrival costs, and in an analytics API the variance between the cheapest and most expensive permitted query is enormous. The limits that bite are the ones denominated in the resource actually being exhausted: - **Concurrency slots per tenant** — the single most effective control, because it directly bounds how much of the pool one tenant can hold at any instant. - **Wall-clock timeouts** on every query, with a lower ceiling for interactive paths than for batch ones. - **Work ceilings**: bytes or partitions scanned, rows returned, result size, join and nesting depth, expansion factor. Reject at plan time where you can — refusing a query before it runs is far cheaper than killing it halfway. - **A budget over a window**: units of work per tenant per hour, so a tenant who is within their concurrency limit but running continuously still hits a ceiling. - **Admission control**: when the pool is above a threshold, refuse new expensive work rather than admitting it and thrashing. ## Isolation: stop sharing the thing being exhausted Quotas bound a tenant; isolation removes the coupling. Practical forms, cheapest first: separate queues per workload class so exports never take a worker reserved for interactive queries; a bulkhead of dedicated workers per tenant tier so the paid tier cannot be starved by the free one; a hard cap on the fraction of the pool any single tenant may occupy; and, at the far end, dedicated infrastructure for the largest tenants. Fair scheduling sits between quotas and isolation — service the queue by tenant in rotation, or by a weighted budget, so a tenant with a thousand queued exports advances at the same rate as a tenant with one. ## Degrade deliberately When the pool saturates anyway, what fails should be a design decision, not luck. Shed by priority: kill or defer batch exports before interactive dashboards, and return a clear, retryable error with a suggested time rather than a timeout. Reject fast when the queue is at its bound — an unbounded queue converts a compute shortage into a memory exhaustion and moves the outage rather than containing it. ## Denial of service with no attacker in the same system The mirror case is worth modeling alongside: the system exhausting itself. Every client retrying the same failed query at the same moment with no jitter; a synchronised refresh that has every device wake at the top of the hour; a cache expiring for all keys at once so every miss stampedes the same backend. The trigger is not an adversary — it is the system's own traffic, amplified by a shared clock or a shared failure. The controls are their own family: retry with exponential backoff **and jitter**, request coalescing so a thousand identical misses become one backend call, circuit breakers that stop the retries during an outage, and staggered schedules instead of round numbers. ## What to expect to be pushed on An interviewer will usually challenge the easy answer. If you say rate limiting, they will ask why one permitted query holding a worker for four minutes is bounded by it. If you say autoscaling, they will ask what happens in the minutes before capacity arrives, and who pays for it. If you say block the tenant, they will ask how you explain that to a paying customer whose report simply got slower. The defensible position is layered: measure per tenant, bound by cost, isolate the lanes, shed by priority, and make the limits documented and visible so a customer can design within them.