63 lines
1.7 KiB
Markdown
63 lines
1.7 KiB
Markdown
<!-- DISCUSSION -->
|
|
<!-- Title: API Rate Limiting -->
|
|
<!-- Phase: consensus_vote -->
|
|
<!-- Status: OPEN -->
|
|
<!-- Created: 2025-12-08T14:00:00Z -->
|
|
<!-- Template: feature -->
|
|
<!-- Participants: architect, security, pragmatist, rob -->
|
|
|
|
# API Rate Limiting
|
|
|
|
## Context
|
|
We need to implement rate limiting to protect our API from abuse and ensure fair usage across all clients.
|
|
|
|
## Requirements
|
|
- [ ] Configurable rate limits per endpoint
|
|
- [ ] Different limits for authenticated vs anonymous users
|
|
- [ ] Clear rate limit headers in responses
|
|
- [ ] Graceful degradation under load
|
|
|
|
## Proposal
|
|
Use a sliding window algorithm with Redis as the backend. Limits configurable via environment variables with sensible defaults (100 req/min for anon, 1000 req/min for authenticated).
|
|
|
|
---
|
|
|
|
*Discussion Summary*
|
|
|
|
---
|
|
|
|
Name: AI-Architect
|
|
The sliding window approach is solid and scales well. Redis is a good choice for this use case - it's fast, battle-tested, and we already have it in our stack.
|
|
|
|
DECISION: Use sliding window algorithm with Redis backend.
|
|
|
|
VOTE: READY
|
|
|
|
---
|
|
|
|
Name: AI-Security
|
|
Rate limiting is essential for security. The proposed limits seem reasonable. I'd suggest also adding:
|
|
- IP-based limiting as a fallback
|
|
- Logging of rate limit violations for monitoring
|
|
|
|
CONCERN: Need to ensure rate limit bypass isn't possible via header manipulation.
|
|
|
|
VOTE: READY
|
|
|
|
---
|
|
|
|
Name: AI-Pragmatist
|
|
This looks good. Redis sliding window is simple to implement and maintain. The limits can always be tuned later based on actual usage patterns.
|
|
|
|
Q: Do we have Redis already deployed, or is this adding new infrastructure?
|
|
|
|
VOTE: READY
|
|
|
|
---
|
|
|
|
Name: Rob
|
|
We already have Redis for caching, so no new infrastructure needed. I'm happy with this approach.
|
|
|
|
VOTE: READY
|
|
|