Application Deployment and Scaling
Relevant source files
The following files were used as context for generating this wiki page:
FastLimit is a high-performance, Redis-backed rate limiting library designed for distributed Python applications. It provides the architectural foundation for scaling API services by ensuring atomic rate limit enforcement across multiple application instances while maintaining sub-millisecond latencies. The system is built for modern asynchronous environments, specifically targeting FastAPI and high-throughput microservices.
Sources: README.md:1-25, pyproject.toml:1-15
Distributed Architecture
FastLimit achieves horizontal scalability by offloading the state of rate limits to a centralized Redis backend. This architecture allows multiple application workers to share the same rate limit counters, preventing users from bypassing limits by hitting different server nodes.
Component Interaction
The system consists of the Python application layer (using RateLimiter), a middleware or decorator layer for request interception, and the Redis storage layer where Lua scripts execute atomic logic.
The diagram shows how multiple application instances interact with a central Redis instance through the RateLimiter client to perform atomic checks.
Sources: README.md:195-210, CONTRIBUTING.md:110-140
Performance and Scaling Targets
FastLimit is optimized for production environments requiring high throughput and low latency. Benchmarking tools within the repository provide targets for deployment validation.
| Metric | Target Value | Description |
|---|---|---|
| p50 Latency | < 2.0ms | Median time for a rate limit check |
| p99 Latency | < 10.0ms | Maximum latency for 99% of requests |
| Throughput (Seq) | > 3,000 req/s | Sequential check capacity per worker |
| Throughput (Con) | > 10,000 req/s | Concurrent check capacity under load |
| Memory per Key | ~100-200 bytes | Redis memory footprint per unique identifier |
Sources: benchmarks/performance.py:15-25, README.md:175-185
Scaling via Multi-Tenancy
For SaaS deployments, FastLimit supports multi-tenant scaling. This allows developers to isolate rate limits based on user tiers (e.g., Free, Premium, Enterprise) or unique tenant identifiers.
Tenant Isolation Flow
The system extracts tenant information from request headers and applies tier-specific logic before reaching the persistence layer.
This flow illustrates the isolation of requests based on tenant metadata, ensuring that one tenant's traffic does not impact another's quota.
Sources: examples/multi_tenant.py:25-60, README.md:145-160
Deployment Configuration
Deployment is typically handled via environment variables and connection pooling to ensure efficient Redis utilization.
Configuration Options
| Parameter | Default | Scaling Impact |
|---|---|---|
redis_url | redis://localhost:6379 | Points to distributed Redis/Elasticache |
key_prefix | ratelimit | Avoids collisions in shared Redis DBs |
enable_metrics | False | Enables Prometheus monitoring for scaling signals |
trust_proxy_headers | False | Required when deployed behind Load Balancers (LB) |
Monitoring for Scale
The prometheus-client integration provides metrics such as fastlimit_checks_total and fastlimit_check_duration_seconds. These metrics are critical for auto-scaling decisions and identifying Redis bottlenecks.
Sources: README.md:100-115, fastlimit/decorators.py:240-260, CONTRIBUTING.md:40-55
Security in Scaled Environments
When deploying behind reverse proxies or load balancers, the trust_proxy_headers setting must be carefully managed. If set to True, the system will use X-Forwarded-For or X-Real-IP to identify clients, which is necessary for accurate IP-based limiting in cloud environments.
# Deployment behind a proxy
limiter = RateLimiter(
redis_url=os.getenv("REDIS_URL"),
trust_proxy_headers=True # Only enable if behind a trusted LB
)
@app.get("/api")
@limiter.limit("100/minute")
async def scaled_endpoint(request: Request):
return {"status": "success"}
Sources: fastlimit/decorators.py:240-275, README.md:115-125
Conclusion
Deployment of FastLimit requires a centralized Redis instance to maintain state consistency across application nodes. By utilizing the built-in multi-tenant support and monitoring metrics, the system can scale to handle tens of thousands of requests per second while providing strict isolation between different users and service tiers.