limits

limits provides rate-limiting primitives for Python applications, implementing fixed-window, moving-window, and sliding-window-counter strategies behind a single RateLimiter interface. Each strategy shares the same hit, test, and get_window_stats methods, so switching strategies (to trade memory efficiency for burst-smoothing accuracy) requires no application code changes.

Storage is pluggable: the same rate-limit definitions work against Redis, Redis Cluster, Redis Sentinel, Memcached, MongoDB, or an in-process memory backend, selected via a storage URI string (e.g. redis://localhost:6379). The library exposes identical sync and async APIs, making it usable from both traditional WSGI applications and async frameworks like FastAPI or Starlette, and is a common building block underneath higher-level framework rate-limiting integrations (e.g. Flask-Limiter).

What You Get

• Three rate-limiting strategies — Fixed Window, Moving Window, and Sliding Window Counter — behind one shared RateLimiter interface
• Storage backends for Redis, Redis Cluster, Redis Sentinel, Memcached, MongoDB, and in-process memory, selected via a storage URI
• Parallel sync and async APIs so the same rate-limit logic works in WSGI or asyncio-based applications
• A RateLimitItem string-parsing syntax (e.g. 10/minute) for expressing rate limits declaratively
• get_window_stats() for exposing remaining quota and reset time to API consumers (e.g. for X-RateLimit-* headers)

Common Use Cases

• Rate-limiting API endpoints in FastAPI, Flask, or Django applications by IP, user ID, or API key
• Sharing rate-limit state across multiple application instances via a shared Redis or Memcached backend
• Powering higher-level framework integrations such as Flask-Limiter that need a pluggable rate-limiting core
• Enforcing sliding-window quotas for third-party API clients with per-tenant rate limits

Under The Hood

Architecture - limits separates rate-limiting logic into strategies.py (an abstract RateLimiter base with FixedWindowRateLimiter, MovingWindowRateLimiter, and SlidingWindowCounterRateLimiter subclasses) from storage/ (backend-specific implementations of a shared Storage protocol — redis.py, memcached.py, mongodb.py, memory.py, plus cluster/sentinel variants), letting any strategy run against any compatible backend without either layer knowing the other’s implementation details. Tech Stack - Pure Python 3.10+ with minimal core dependencies (deprecated, packaging, typing_extensions); backend-specific client libraries (redis-py, pymemcache, pymongo) are optional extras installed only when that backend is used, and an aio subpackage mirrors the sync storage/strategy classes for asyncio support. Code Quality - 23 test files cover strategies and every storage backend (run against real Redis/Memcached/MongoDB via docker-compose.yml in CI), the package ships py.typed for full type-checker support, and the codebase is fully type-annotated using from __future__ import annotations. API Design - A single storage URI string (redis://..., memcached://...) plus a compact rate-limit string syntax (10/minute) covers most usage, and identical method names (hit, test, get_window_stats) across all three strategies and both sync/async variants keep the API surface small and predictable.