Rate Limiting, Throttling and Quota Management Questions

Approach: use a per-key token-bucket tracked in memory. Each bucket stores (tokens, last_ts). On each allow_request(key) call we atomically (thread-safe) refill based on elapsed time, cap at burst capacity, then consume 1 token if available and return True/False. Use per-key locks (or a single lock for simplicity) to be safe under threads. Non-blocking: returns immediately.

import time
import threading
from collections import defaultdict

class TokenBucket:
    def __init__(self, rate, capacity):
        """
        rate: tokens per second
        capacity: max tokens (burst capacity)
        """
        self.rate = float(rate)
        self.capacity = float(capacity)
        self.tokens = capacity
        self.last_ts = time.monotonic()
        self.lock = threading.Lock()

    def allow(self, tokens=1):
        with self.lock:
            now = time.monotonic()
            # refill
            elapsed = now - self.last_ts
            self.last_ts = now
            self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
            if self.tokens >= tokens:
                self.tokens -= tokens
                return True
            return False

class RateLimiter:
    def __init__(self, rate, capacity):
        self.rate = rate
        self.capacity = capacity
        self.buckets = defaultdict(lambda: TokenBucket(rate, capacity))
        self.global_lock = threading.Lock()  # protects creation race

    def allow_request(self, key):
        # ensure bucket exists in a thread-safe way
        with self.global_lock:
            bucket = self.buckets[key]
        return bucket.allow(1)

Key points:

• Uses time.monotonic() to avoid clock jumps.
• Per-bucket lock keeps contention low for many users.
• Non-blocking: allow_request returns immediately.

Complexity:

• Time: O(1) per request.
• Space: O(U) for U active users.

Edge cases:

• Large number of distinct keys -> memory growth; use eviction (LRU) for inactive keys.
• Very high rate -> floating precision; consider using integers or microsecond units.
• Burst capacity 0 -> effectively blocks all.

Distributed extension:

• Use a central store with atomic operations, e.g., Redis + Lua script implementing token refill & consume in one atomic step. The Lua script computes refill based on stored last_ts and tokens, caps at capacity, decrements if possible and returns allowed boolean. This avoids race conditions across processes. Consider clock skew by using server-side time (TIME command) or monotonic server timestamp. For extreme scale, use local token caches for low-latency checks and periodically reconcile with Redis (sharded by key). Trade-offs: central Redis adds network latency and single point of failure; mitigate with clustering and replication.

Requirements & constraints:

• Multi-tenant controls: per-user, per-api-key, per-IP
• Support bursts, steady-rate limits, priority tiers (e.g., paid, free, enterprise)
• Integrate with billing (quota metering, overage, throttling to protect expensive models)
• Low latency (prediction path), high availability, and accurate enforcement in distributed environment

Design overview:

• Use token-bucket for burst + steady-rate (allows bursts up to bucket size, refills at rate R). Use leaky-bucket (fixed dequeue) when you want smoothing and strict pacing.
• Primary enforcement at an edge admission-control layer (API gateway / Envoy filter / custom sidecar) to reject or queue requests before hitting model-serving infra.
• Central policy store (Config DB + billing service) holds limits per api-key/user/IP and priority tier. Policies propagated to edge via watch/stream (etcd/Consul/Push config).

Algorithmic choices:

• Token-bucket per key-tier: tokens refilled at rate R; bucket size = burst allowance. Higher-tier users get larger R and bucket.
• Implement weighted tokens for model-cost: different models consume different token counts (expensive model consumes more).
• Leaky-bucket used for background queue draining if we want constant output rate to model for capacity smoothing.

Distributed enforcement:

• Two-level enforcement:
  1. Local fast-path at each edge instance maintaining in-memory token-buckets for hot keys (O(1) check) for low latency.
  2. Global consistency via a central quota service for strong limits and billing counters. Edges periodically sync counters and fall back to central service when uncertain.
• Use probabilistic or approximate counters (Redis with INCR + TTL or Redis Streams) for performance. For stricter guarantees, use Redis with Lua scripts for atomic token consume across cluster, at cost of network hop.
• To avoid hot-keys overload, shard keys across Redis clusters and use local cached tokens with refill reconciliation to central store.

Billing integration:

• Meter token consumption events to billing service asynchronously (Kafka). Map token usage -> billable units (e.g., token weight × model-cost). Enforce hard caps by central quota (reject once central counter shows limit exceeded) or soft caps with grace overage.

Trade-offs:

• Accuracy vs latency: Local in-memory buckets = very low latency but eventual consistency; central atomic checks = accurate but adds RTT and single-point sensitivity.
• Complexity vs cost: Weighted tokens and per-model costing increase fairness but add complexity to policy and metering.
• Burst allowance protects UX but risks sudden load; set global circuit-breakers to protect model-serving clusters.
• Security: API-key spoofing — authenticate and bind keys to IP/user to prevent circumvention.

Edge behaviors:

• Priority tiers: when overloaded, use priority queueing—serve high-tier first, ration low-tier via dynamic rate reduction.
• Graceful degradation: return 429 with Retry-After, or enqueue in short-lived admission queue with backpressure.

Metrics & monitoring:

• Track token consumption, rejected requests, latency, per-key errors; alert on hot-key overload and billing anomalies.

This design balances low-latency enforcement with global correctness by combining local token-buckets for speed and a central quota/billing service for accurate metering and hard limits.

Approach: use a token-bucket per user stored in Redis. Each request runs a single atomic Lua script that: (1) computes tokens to add since last refill using server time passed in by client or server time from Redis (prefer Redis time to avoid clock skew), (2) clamps tokens to capacity, (3) if tokens >= 1 subtracts 1 and allow, else reject. Using a Lua script ensures atomic read-modify-write.

Lua script (uses Redis TIME to avoid client clock skew):

-- ARGV: user_key, capacity, refill_rate_per_sec (tokens/sec)
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local rate = tonumber(ARGV[2])

local now = redis.call('TIME')           -- returns {sec, usec}
local now_sec = tonumber(now[1]) + tonumber(now[2]) / 1e6

local data = redis.call('HMGET', key, 'tokens', 'last_ts')
local tokens = tonumber(data[1]) or capacity
local last_ts = tonumber(data[2]) or now_sec

local delta = math.max(0, now_sec - last_ts)
tokens = math.min(capacity, tokens + delta * rate)
local allowed = 0
if tokens >= 1 then
  tokens = tokens - 1
  allowed = 1
end

redis.call('HMSET', key, 'tokens', tokens, 'last_ts', now_sec)
redis.call('EXPIRE', key, math.ceil(math.max(60, capacity / rate * 2))) -- auto cleanup

return {allowed, tokens}

Why this works:

• Atomicity: single Lua script executes atomically in Redis (no interleaving).
• Clock skew: script uses Redis TIME, providing a single authoritative clock for all instances. Avoid passing client/server times.
• Hot-key mitigation:
  • Shard per-user keyspace across Redis cluster (user ID hashing).
  • For extremely hot users, apply hierarchical limits: first a coarse-grained front-line in-process leaky bucket (fast local allow with occasional Redis check) to short-circuit most requests and reduce Redis QPS.
  • Use batching or probabilistic sampling for non-critical requests.
  • Use Redis Cluster with key hash tags to distribute hot user across slots if you can shard by sub-IDs (e.g., user:123 -> user:123:0..N) and aggregate counters periodically.
• Edge cases: network partitions (fail-open vs fail-closed policy), burst correctness (capacity must permit desired bursts), precision: using float tokens, ensure serialization format consistent.
• Alternatives: use Redis sorted sets with timestamps (sliding window) or Redis tokens with INCR+EXPIRE (fixed window) for simpler guarantees. The Lua token-bucket balances accuracy and performance.