Rate Limits per Endpoint (Cost-Aware)#542
Open
Menjay7 wants to merge 6 commits into
Open
Conversation
- Add 'disbursing' status to ClaimStatus enum - Modify disburse method to enqueue background jobs with BullMQ - Add ClaimRetryService to monitor and handle stuck disbursements - Update on-chain processor to transition claim status on success/failure - Add automatic retry with exponential backoff (5 attempts) - Add monitoring cron job running every 5 minutes - Revert claims to 'approved' after max retry attempts
- Add @ratelimit decorator for endpoint-specific configuration - Create CostAwareRateLimitGuard with cost-aware rate limiting - Implement automatic cost calculation based on HTTP method and path - Add rate limit headers (Limit, Remaining, Reset, Cost, Window) - Apply rate limits to claims endpoints (create, disburse) - Apply rate limits to verification endpoint (enqueue) - Add comprehensive documentation Default costs: - Read operations: 1 - Write operations: 5 - Expensive operations (on-chain): 20 - Bulk operations: 50
|
@Menjay7 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
Contributor
|
Please resolve conflicts |
Author
|
Done boss @Cedarich |
Contributor
|
Please fix workflow |
- Replace PrismaService injection with MetricsService in OnchainProcessor - Add metrics recording for contract call latency and failures - Add correlationId logging for better traceability - Remove claim status update logic (updateClaimStatus, revertClaimStatus methods) - Add new metrics methods: recordContractCallLatency, incrementTxSubmissionFailure, incrementCallbackFailure - Update onFailed handler to use metrics instead of claim status reversion
Resolved merge conflicts in onchain.processor.ts: - Kept MetricsService injection (removed PrismaService) - Kept metrics recording in process and onFailed methods - Removed claim status update logic (updateClaimStatus, revertClaimStatus) - Fixed duplicate imports
Contributor
|
Fix failing test |
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
3 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.
Summary
This PR introduces endpoint-specific, cost-aware rate limiting to better manage resource consumption, protect critical services, and ensure fair usage across the platform. Different API endpoints can now enforce tailored rate limits based on their computational cost and operational impact.
Changes Made
Added configurable rate limits on a per-endpoint basis.
Introduced cost-aware request weighting to account for varying endpoint resource usage.
Implemented support for endpoint-specific quotas and throttling policies.
Added centralized configuration for managing rate limit rules.
Enhanced rate limit response headers to provide visibility into usage and remaining quota.
Added monitoring and logging for rate limit events.
Added unit and integration tests covering rate limit enforcement scenarios.
Problem
A uniform rate-limiting strategy treats all requests equally, regardless of their computational cost. This can lead to inefficient resource allocation, increased operational costs, and reduced service availability during high-traffic periods.
Solution
Endpoints are now assigned configurable cost weights, allowing rate limits to reflect actual resource consumption. High-cost operations consume more quota than lightweight requests, resulting in fairer and more efficient usage patterns.
Key Features
Endpoint-Specific Limits
Configure independent limits for each API endpoint.
Support different limits based on endpoint sensitivity and resource usage.
Cost-Aware Consumption
Assign request weights based on computational complexity.
Deduct quota proportionally to endpoint cost.
Enhanced Visibility
Expose rate limit information through response headers.
Improve observability with structured logging and metrics.
Flexible Configuration
Support environment-specific rate limit policies.
Allow easy adjustment of endpoint costs and quotas without code changes.
Testing
Unit Tests
Rate limit calculation and quota consumption.
Cost-weight application per endpoint.
Quota reset and replenishment behavior.
Configuration validation.
Integration Tests
Enforcement of endpoint-specific limits.
Mixed endpoint traffic with different cost weights.
Proper response codes when limits are exceeded.
Verification of rate limit headers and usage tracking.
Impact
Fairer distribution of system resources.
Reduced risk of abuse on expensive endpoints.
Improved service stability under load.
Better alignment between usage and infrastructure costs.
Increased operational visibility and control.
Type of Change
Feature
Infrastructure Improvement
Performance Optimization..closed #460