0x1d
6a17236474
- Add comprehensive 8-phase implementation plan (docs/plan.md) - Add 28 Architecture Decision Records (docs/adr/) covering all phases - Add task tracking system with 283+ task files (docs/stories/) - Add task generator script for automated task file creation - Add reference playbooks and requirements documentation This commit establishes the complete planning foundation for the Go Platform implementation, documenting all architectural decisions and providing detailed task breakdown for Phases 0-8.
1.6 KiB
1.6 KiB
ADR-0027: Rate Limiting Strategy
Status
Accepted
Context
The platform needs rate limiting to:
- Prevent abuse and DoS attacks
- Protect against brute-force attacks
- Ensure fair resource usage
- Comply with API usage policies
Rate limiting strategies:
- Per-user rate limiting - Based on authenticated user
- Per-IP rate limiting - Based on client IP
- Fixed rate limiting - Global limits
- Distributed rate limiting - Shared state across instances
Decision
Implement multi-level rate limiting:
- Per-user rate limiting: For authenticated requests (e.g., 100 req/min)
- Per-IP rate limiting: For all requests (e.g., 1000 req/min)
- Storage: Redis for distributed rate limiting
- Algorithm: Token bucket or sliding window
Rationale:
- Multi-level provides defense in depth
- Per-user prevents abuse by authenticated users
- Per-IP protects against unauthenticated abuse
- Redis enables distributed rate limiting (multi-instance)
- Token bucket provides smooth rate limiting
Consequences
Positive
- Multi-layer protection
- Works with multiple instances
- Configurable per endpoint
- Standard approach
Negative
- Requires Redis (or shared state)
- Additional latency (minimal)
- Need to handle Redis failures gracefully
Implementation Notes
- Use
github.com/ulule/limiter/v3library - Configure limits in config file
- Store rate limit state in Redis
- Return
X-RateLimit-*headers - Handle Redis failures gracefully (fail open or closed based on config)
- Configure different limits for different endpoints