Edge Rate Limiting: Leaky Bucket vs. Token Bucket Architectures in Cloudflare Durable Objects

## Distributed Rate Limiting at Network Perimeters

Protecting public API surfaces from automated scraping, brute-force credential stuffing, and volumetric denial-of-service requires sub-millisecond rate evaluation. Evaluating rate quotas after a request reaches the origin application server squanders compute resources on malicious traffic.

### 1. Algorithm Comparison and Edge Performance

| Rate Limiting Model | Burst Tolerance | Smoothing Effect | Memory Footprint / Client | Synchronization Overhead |
|:--------------------|:---------------:|:----------------:|:-------------------------:|:------------------------:|
| Fixed Window Counter | High (Edge Spill) | None | 8 bytes | Low |
| Sliding Window Log | Zero | Strict | 128 - 512 bytes | High (List Pruning) |
| Token Bucket | Controlled Burst | Moderate | 16 bytes | Zero (Actor-Local) |
| Leaky Bucket | None | Maximum Smooth | 16 bytes | Zero (Actor-Local) |

### 2. Durable Object Actor Implementation

By routing client requests based on hashed client IP or API key to a dedicated Cloudflare Durable Object, state synchronization is maintained without external locks:

```python
class RateLimiterActor:
def __init__(self, capacity: int, refill_rate_per_sec: float):
self.capacity = capacity
self.refill_rate = refill_rate_per_sec
self.tokens = capacity
self.last_refill = time.time()

def allow_request(self, cost: int = 1) -> bool:
now = time.time()
elapsed = now - self.last_refill
self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)
self.last_refill = now
if self.tokens >= cost:
self.tokens -= cost
return True
return False
```