feat: add IP-based rate limiting with Redis-backed sliding window#18
Merged
feat: add IP-based rate limiting with Redis-backed sliding window#18
Conversation
Introduce configurable rate limiting to protect expensive endpoints and prevent abuse. The implementation uses Redis for distributed state so limits are enforced consistently across multiple server instances. Key additions: - New `rate_limiting` config section with rules, exempt IPs, and failure mode (fail-open/fail-closed). - `ratelimit.Service` backed by Redis INCR+EXPIRE sliding-window logic. - Middleware that applies the first matching rule based on request path regex, adds standard `X-RateLimit-*` and `Retry-After` headers, and emits Prometheus metrics. - Comprehensive unit and integration tests, including miniredis-based concurrency and failure-mode scenarios. The middleware is inserted after CORS but before recovery so that rate-limit responses are returned early and consistently.
…ignature refactor(server.go): reorder RateLimit parameters to logger-first convention
Check Redis availability during Start() and log the result. When failure_mode is "fail_closed", abort startup if Redis is unreachable to prevent the service from running in a broken state.
samcm
approved these changes
Oct 28, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Introduce configurable rate limiting to protect expensive endpoints and prevent abuse. The implementation uses Redis for distributed state so limits are enforced consistently across multiple server instances.
Key additions:
rate_limitingconfig section with rules, exempt IPs, and failure mode (fail-open/fail-closed).ratelimit.Servicebacked by Redis INCR+EXPIRE sliding-window logic.X-RateLimit-*andRetry-Afterheaders, and emits Prometheus metrics.The middleware is inserted after CORS but before recovery so that rate-limit responses are returned early and consistently.
========================================== Burst Rate Limiting Test ========================================== Configuration: URL: http://localhost:8080/api/v1/mainnet/bounds Requests: 70 (all at once) Firing 70 concurrent requests NOW... ✓ All requests completed Results: ✓ Allowed: 30 ✗ Denied: 40 Sample 429 Response: {"error":"rate limit exceeded","retry_after":59,"status":429} ✓ Rate limiting works! Denied 40 out of 70 requests