Rate limiting a noisy tenant is the easy part. The hard part is proving everyone else was actually fine while you did it, and being precise about what "fine" means.
That's what I built quota-sentinel to work through: a multi-tenant API gateway enforcing per-tenant quotas, tested specifically against one tenant deliberately trying to consume more than its share.
The setup
A FastAPI gateway sits in front of an upstream service. Every request carries a tenant ID, and Redis tracks each tenant's usage against a configured quota ceiling using a sliding-window log, atomic Lua scripts handle the purge/add/count sequence so there's no race condition between checking a tenant's count and incrementing it.
Tenants are configured across tiers with different ceilings:
- Free tier: 5 req/min
- Standard tier: 20 req/min
- Premium tier: 60 req/min
Proving isolation, not just rate limiting
The design is easy to state and easy to get wrong in practice, so I tested it by deliberately flooding one tenant with traffic while other tenants ran independently, and watched what happened to all of them, not just the one being throttled.
tenant-noisy was sent a sustained burst well above its 5 req/min ceiling. It got throttled, hard, exactly as expected.
What the dashboard actually showed, and why I almost got the conclusion wrong
My first instinct was to write this up as "the noisy tenant was throttled and everyone else was unaffected." Looking closer at the Grafana panels, that wasn't quite true, and the reason why turned out to be the more interesting finding.
tenant-free also showed throttled requests during the same window. My first reaction was that something was leaking, that the noisy tenant's flood was somehow bleeding into another tenant's quota. It wasn't. tenant-free shares the same 5 req/min free-tier ceiling as tenant-noisy, and it was independently generating enough of its own traffic to hit its own limit. Redis tracks quota per tenant key, there's no shared counter between tenants on the same tier, so tenant-free being throttled was its own traffic against its own budget, completely unrelated to what tenant-noisy was doing.
The tenant that actually proves isolation is tenant-standard, on a separate 20 req/min tier. Across the entire test window, it shows zero throttled requests. That's the real claim this project can make: a tenant on a different tier is fully isolated from another tenant's excess traffic, not that every tenant everywhere is magically unaffected by everything.
That distinction matters. "Nobody else was throttled" would have been a comfortable thing to write and a wrong one. "Tenants don't compete for each other's quota, they only ever compete against their own" is a more precise, more defensible claim, and it's the one the evidence actually supports.
What this project didn't try to be
This is not intended to be a replacement for an enterprise API gateway. A sliding-window Redis implementation is only one approach; token buckets and fixed windows both carry valid operational trade-offs documented in the repository.
What it proves concretely is that per-tenant isolation holds under real, adversarial traffic patterns, and that claiming fairness requires verifying every tenant's telemetry during a failure scenario, not just the one you are actively breaking.
Top comments (0)