Current rate limiting is global per the entire application. We need to implement per-user/per-issuer rate limiting to prevent single actors from monopolizing resources. This includes tracking per-issuer request quotas, implementing burst tolerance, and exposing rate limit metrics. Rate limit violations should be tracked and exposed via the metrics system for monitoring and alerting.
Affected Files:
src/rate_limit.rs (implement per-key rate limiting)src/metrics.rs (add rate limit metrics tracking)src/config.rs (add per-issuer rate limit configuration)
Acceptance Criteria:
- Replace global rate limiter with keyed rate limiter using issuer address as key
- Implement two-tier limits: per-issuer and global (with global taking precedence)
- Add configuration for per-issuer rate limits (e.g., 1000 requests/hour)
- Add metrics:
rate_limit_hits_total, rate_limit_rejections_total (per issuer)
- Implement graceful rate limit response with Retry-After header
- Add endpoint to retrieve current rate limit status for user (remaining quota, reset time)
- Persist rate limit state to cache for distributed consistency
- Add tests for per-issuer rate limiting and burst scenarios
- Document rate limit tiers and quotas in API documentation
Impact:
- Fair resource allocation
- Prevents abuse and DoS scenarios
- Better observability of system load
Current rate limiting is global per the entire application. We need to implement per-user/per-issuer rate limiting to prevent single actors from monopolizing resources. This includes tracking per-issuer request quotas, implementing burst tolerance, and exposing rate limit metrics. Rate limit violations should be tracked and exposed via the metrics system for monitoring and alerting.
Affected Files:
src/rate_limit.rs(implement per-key rate limiting)src/metrics.rs(add rate limit metrics tracking)src/config.rs(add per-issuer rate limit configuration)Acceptance Criteria:
rate_limit_hits_total,rate_limit_rejections_total(per issuer)Impact: