Design a rate limiter for an API.
Discuss the functional requirements, non-functional requirements, API design, high-level architecture, and data model for a scalable rate limiting service.
Example API design:
POST /check
Checks if a request is allowed under the current limits.
Request:
{
"user_ip": "some user",
"api_id": "some api"
}Response:
{
"allowed": true,
"remaining": 14,
"reset_in_seconds": 19
}POST /configure
Creates or updates rate limit rules for the server.
Request body:
{
"api_id": "some api",
"limits": [{ "limit_key": "minute", "limit": 100},
{"limit_key": "daily", "limit": 10000}
]
}This is a classic system design problem about building a scalable API rate limiter. The core requirements are low latency, high availability, and support for configurable rules per api_id and user_ip, with endpoints such as /check and /configure. A practical design uses Redis for fast in-memory access, atomic updates via Lua, and a token bucket-style data model that stores the current token count plus the last refill timestamp so the service can refill tokens based on elapsed time.
