Rate Limiter Service

Rate limiting is a foundational building block for any API platform, yet implementing it correctly in a distributed environment is surprisingly nuanced. Simple in-memory counters fail when your API runs across multiple instances, and naive database-based approaches add unacceptable latency to every request. In this challenge, you will design a distributed rate limiter that supports multiple strategies — fixed window, sliding window log, sliding window counter, and token bucket — and can be deployed as a shared service across an entire API platform. The core implementation uses Amazon ElastiCache for Redis with Lua scripts for atomic increment-and-check operations, ensuring that concurrent requests across multiple API Gateway instances get consistent rate limit decisions. You will design the configuration layer in DynamoDB, where rate limit rules are defined per API key, per endpoint, per IP, or per user with hierarchical overrides. The architecture includes a sliding window counter implementation using two Redis keys per window with weighted scoring, providing accuracy close to the sliding window log algorithm at a fraction of the memory cost. For enterprise scenarios, you will add a distributed token bucket that supports burst allowances and graceful degradation. The system publishes rate limit events to EventBridge, enabling downstream analytics on API abuse patterns and automated blocking via WAF rule updates. Headers follow the IETF draft RateLimit standard (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset). This challenge teaches distributed counting, atomic operations in Redis, and the trade-offs between accuracy and performance in rate limiting algorithms.