FAIRVISORFairvisor vs. Envoy Rate Limiting
The Situation
Envoy rate limiting (lyft/ratelimit) is a proven pattern in Envoy-centric stacks, but it typically depends on external services and Redis.
Fairvisor provides in-process AI-aware enforcement with no Redis dependency on the request path.
Comparison
| Capability | Fairvisor | Envoy Rate Limit Service (lyft/ratelimit) |
|---|---|---|
| Architecture | In-process (OpenResty/LuaJIT) | External gRPC service + Redis |
| External dependencies | None (MVP) | Redis (required) |
| Latency profile | In-process decision path | External call path (gateway -> service -> Redis) |
| Limit keys | JWT claims, headers, path, UA, combinations | Headers, path from Envoy descriptors |
| Cost-based budgets | Yes | No |
| AI features | Loop detection, token counting, circuit breaker, AI crawler detection | No |
| Staged actions | Warn -> throttle -> reject | Reject (binary) |
| Shadow mode | Yes | No |
| Management UI | SaaS dashboard | None (YAML config) |
| Analytics | Per-tenant dashboard, cost attribution | Prometheus counters |
| High availability | In-process, no external SPOF in hot path | Redis SPOF unless clustered |
When to Use Fairvisor
- You need AI-aware enforcement and cost-based budgets.
- You want to avoid Redis dependency on policy decisions.
- You want a management plane and richer analytics.
When to Use Envoy Rate Limit Service
- You are deeply invested in Envoy/Istio descriptor patterns.
- You only need straightforward descriptor-based limits.
- Redis is already part of your accepted control stack.
Use Them Together
- Envoy can continue handling core proxy routing.
- Fairvisor can provide advanced decisions via
ext_authz. - You can introduce AI-aware policies without replacing Envoy.