Appearance
14.10 API Design & Recipient Rate Limiting
1. Token Bucket vs Leaky Bucket vs Sliding Window
| Algorithm | Smooth Bursts? | Memory Footprint | Enforcement Location | Fit for OmniPost |
|---|---|---|---|---|
| Token Bucket (Chosen) | Yes (allows burst up to capacity) | $O(1)$ per key (tokens, timestamp) | queues/dispatcher.py:24 | Optimal for provider API quotas |
| Leaky Bucket | No (enforces strict constant rate) | $O(1)$ | Traffic shaping queues | Better for egress smoothing |
| Sliding Window Log | Yes | $O(N)$ (stores every timestamp) | Redis Sorted Sets | Memory intensive |
| Fixed Window Counter | Vulnerable to boundary spikes | $O(1)$ | Counter cache | Poor burst protection |
2. Say It Out Loud
"We implement token bucket rate limiting in
queues/dispatcher.pyto protect upstream carrier quotas. The token bucket smoothly accommodates legitimate bursts of OTP requests while strictly bounding average delivery throughput to provider limits (such as Twilio's 100 SMS per second). Unlike fixed-window limiters, the token bucket eliminates traffic spikes at window boundaries."