limits

limits is a Python library designed for rate limiting using multiple strategies and common storage backends. It is built to provide identical APIs for both synchronous and asynchronous codebases, making it versatile for different Python application architectures.

Key Features

• Multiple Strategies: Supports various rate-limiting algorithms (e.g., Fixed Window, Moving Window, Sliding Window Counter).
• Storage Backends: Integrates with Redis, Memcached, and MongoDB.
• Sync & Async Support: Provides consistent APIs for both execution models.

Choose a strategy based on your requirements for memory usage, performance, and accuracy:

• Fixed Window: Best for high performance and low memory usage. Use this when occasional bursts at window boundaries are acceptable. You can mitigate burstiness by combining a large window limit with a finer-grained one (e.g., 10 requests per minute AND 2 requests per second).
• Moving Window: Best for absolute accuracy. Use this when you need exact rate limiting and can afford the extra memory overhead required to store request timestamps.
• Sliding Window Counter: Best for a balance between memory efficiency and accuracy. It smooths transitions between time periods with less overhead than a Moving Window, though it may trade off some precision near bucket boundaries.

The Fixed Window strategy is the most memory-efficient option because it only requires a single counter per resource and rate limit.

How it works:

1. When the first request arrives, a window starts for a fixed duration (e.g., 60 seconds for a 'per minute' limit).
2. All requests within that window increment the counter.
3. Once the window expires, the counter resets and a new window begins.

Trade-offs:

• Pros: Extremely low memory usage and high performance.
• Cons: Can allow burst traffic at the boundaries of windows (e.g., if the limit is 10/min, a user could theoretically send 10 requests at the very end of one window and 10 at the very start of the next).

The Moving Window strategy provides exact rate limiting by tracking individual request timestamps.

How it works:

1. The system maintains a log of request timestamps.
2. When a new request arrives, the system checks the timestamp of the nth oldest entry (where n is your limit).
3. If that entry is older than the window duration (or doesn't exist), the request is allowed and the new timestamp is added to the log.
4. Expired entries are truncated from the log.

Trade-offs:

• Pros: Perfectly accurate; no burstiness at window boundaries.
• Cons: Higher memory overhead because it must store a timestamp for every request within the window.

The performance and storage costs of limits depend on the chosen strategy and storage backend.

Strategy Comparison

• Fixed Window and Sliding Window Counter: Both strategies maintain relatively constant storage costs and operation performance, regardless of the window size or the limit amount.
• Moving Window: This strategy maintains a complete log of all successful requests within the rate limit window. Consequently, its storage cost and computational overhead increase as the limit size or the load increases.

When choosing a strategy, consider if your application requires the precision of a Moving Window or if the constant-cost characteristics of Fixed Window or Sliding Window Counter are more suitable for your scale.

The performance of the limits library is measured across three primary method categories. When benchmarking or selecting a strategy, consider the throughput and latency of these specific operations:

1. hit(): The primary method for incrementing the counter and checking the limit.
2. test(): Checks if a request would exceed the limit without actually incrementing the counter.
3. get_window_stats(): Retrieves metadata and statistics regarding the current rate limit window.

Performance varies significantly based on the combination of the storage backend (e.g., Redis, Memcached, MongoDB) and the rate-limiting strategy used.

You can use several storage backends to persist rate limit data. The library supports In-Memory, Memcached, Redis, and MongoDB. You can initialize them by calling the specific storage class or by using the storage_from_string factory method with a connection URI.

Supported connection URI formats:

• Memcached: memcached://localhost:11211
• Redis: redis://localhost:6379
• MongoDB: mongodb://localhost:27017

from limits import storage

# Specific classes
backend = storage.MemoryStorage()
backend = storage.MemcachedStorage("memcached://localhost:11211")
backend = storage.RedisStorage("redis://localhost:6379")
backend = storage.MongoDbStorage("mongodb://localhost:27017")

# Using the factory
storage_uri = "redis://localhost:6379"
backend = storage.storage_from_string(storage_uri)

A rate limiter requires a storage backend and a strategy. Choose a strategy based on your requirements:

• FixedWindowRateLimiter: Resets the window at fixed intervals.
• MovingWindowRateLimiter: A sliding window approach. Caution: If the storage backend does not support this, a NotImplementedError will be raised.
• SlidingWindowCounterRateLimiter: Uses a sliding window counter. Caution: If the storage backend does not support this, a NotImplementedError will be raised.

from limits import strategies

# Fixed window
limiter = strategies.FixedWindowRateLimiter(limits_storage)

# Moving window
limiter = strategies.MovingWindowRateLimiter(limits_storage)

# Sliding window counter
limiter = strategies.SlidingWindowCounterRateLimiter(limits_storage)

You can install specific storage backend dependencies using pip extras:

• Redis: $ pip install limits[redis]
• RedisCluster: $ pip install limits[rediscluster]
• Memcached: $ pip install limits[memcached]
• MongoDB: $ pip install limits[mongodb]
• Valkey: $ pip install limits[valkey]