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}
]
}
这道题是典型的 Rate Limiter 系统设计题,核心是围绕“按 user_ip + api_id 做限流”来设计一个低延迟、高可用、可扩展的服务。题目里提到可配置的 /check 和 /configure 接口,说明我们需要支持查询是否允许请求、返回剩余配额和重置时间,同时允许按分钟、按天等不同维度动态更新规则。实现上通常会选择 Redis 这类内存型存储来保证单次判断足够快,并用原子操作或 Lua 脚本避免并发下的竞态问题;数据模型可用 key=ratelimit:{api_id}:{user_ip} 保存当前 token 数和上次补充时间,再根据时间差按固定速率补充 token,适合用 token bucket 思路来平衡突发流量与长期吞吐。