FAIRVISORFairvisor vs. Nginx limit_req
The Situation
Nginx limit_req and limit_conn are solid primitives for simple traffic protection.
But modern AI and multi-tenant APIs need richer dimensions: tenant-aware limits, budget controls, staged enforcement, and analytics.
Comparison
| Capability | Fairvisor | Nginx limit_req / limit_conn |
|---|---|---|
| Algorithm | Token bucket + cost-based + token-based | Leaky bucket (limit_req), connection count (limit_conn) |
| Limit keys | JWT claims, headers, path, User-Agent, IP, combinations | $binary_remote_addr and limited variables |
| Per-tenant isolation | Yes (any JWT claim) | No (IP-focused unless custom scripting) |
| Cost-based budgets | Yes | No |
| AI features | Loop detection, token counting, circuit breaker | No |
| Staged actions | Warn -> throttle -> reject | Reject or delay |
| Shadow mode | Yes | No |
| Dynamic config | Policy hot-reload, SaaS management | Requires reload |
| Analytics | Dashboard, per-tenant breakdown, export | Basic status + log parsing |
| Kill-switch | Yes, propagated in < 10s | Manual config change + reload |
When to Use Fairvisor
- You need business-context-aware limits (tenant, plan, endpoint).
- You need AI-specific enforcement and budget controls.
- You want management UI and operational analytics.
When to Use Nginx limit_req
- Simple IP-based limiting is enough.
- You have a small set of endpoints and static rules.
- You do not need tenant analytics or staged policy workflows.
Use Them Together
- Fairvisor runs on OpenResty/Nginx runtime foundations.
- Migration can be incremental: policy replacement, not full infra replacement.
- Keep your Nginx stack while upgrading enforcement depth.