Rate limiting with Redis

Summary

Rate limiting at Ramp must handle third-party API quotas, globally paced Celery tasks, and inbound API traffic limited by authenticated application identities rather than only mutable IP addresses. Celery’s per-worker controls were insufficient for global limits, while queue prefetching could let rate-limited tasks block workers and stall queues. The team created a general framework for comparing algorithms and evaluated fixed-window, sliding-window, leaky/token-bucket, and Generic Cell Rate Algorithm (GCRA) approaches. They selected GCRA for implementation simplicity and compute and memory efficiency, storing a theoretical arrival time in Redis and using a Redis lock to prevent races. The implementation also uses floating-point timestamps, Redis server time, key expiration, unit tests, and manual testing; it has been introduced gradually across the three use cases, with monitoring, while additional algorithms remain planned.

Takeaways

1. 1

   GCRA was chosen over fixed-window, sliding-window, and leaky/token-bucket approaches because the team considered its implementation simplicity and compute and memory efficiency suitable for most use cases.

2. 2

   The implementation uses Redis time instead of each application server’s clock, since server clocks may differ, and stores timestamps as floats for higher precision.

3. 3

   Celery’s built-in rate limiting is per-worker; distributing a desired global limit across workers requires awareness of queue placement, worker counts, and autoscaling behavior, and may still over-limit traffic.