Rate Limiter Simulator

Rate limiting: Restricting the number of requests a client can make to an API within a time window. Common limits: 100 requests per minute, 1000 requests per hour, 10,000 requests per day. Why APIs use rate limiting: 1. Prevent abuse: Stop malicious actors from overwhelming servers (DDoS attacks). Prevent scraping/data harvesting. Limit impact of buggy client code (infinite loops making requests). 2. Fair resource allocation: Ensure all users get reasonable access. Prevent single user from monopolizing resources. 3. Cost control: Limit infrastructure costs (bandwidth, compute, database queries). Prevent unexpected scaling costs. 4. Service quality: Maintain performance for all users. Prevent server overload and downtime. 5. Monetization: Free tier: low limits (100 req/hour). Paid tier: higher limits (10,000 req/hour). Enterprise: unlimited or very high limits. Common limit types: Per-user limits: Based on API key, OAuth token, or IP address. Different limits for different users/tiers. Per-endpoint limits: Stricter limits on expensive operations (search: 10/min, simple GET: 100/min). Global limits: Overall API capacity (1M requests/hour across all users). Burst limits: Short-term high usage allowed (100/sec burst, 1000/hour sustained). How clients detect rate limits: Response headers: X-RateLimit-Limit: 100 (max requests per window), X-RateLimit-Remaining: 45 (requests left), X-RateLimit-Reset: 1640000000 (Unix timestamp when limit resets). 429 status code: 'Too Many Requests' when limit exceeded. Retry-After header indicates when to retry. Use this simulator to understand rate limit behavior and test your client's handling of rate-limited responses.

1. Fixed Window: Count requests in fixed time windows (e.g., 0:00-0:59, 1:00-1:59). Limit: 100 requests per minute. At 0:45, made 99 requests. At 1:00, counter resets to 0. Pros: Simple to implement (single counter per window). Low memory usage. Cons: Burst at window boundaries (99 requests at 0:59, 100 more at 1:00 = 199 in 2 seconds). Unfair to users who spread requests evenly. 2. Sliding Window Log: Track timestamp of each request. Count requests in last N seconds from current time. Example: At 1:00:30, count all requests since 0:59:30. Pros: Precise rate limiting. No boundary burst issues. Cons: High memory usage (store every request timestamp). Slower (scan all timestamps on each request). 3. Sliding Window Counter: Hybrid of fixed window and sliding log. Calculate weighted average of current and previous window. Formula: rate = (prevWindow * overlap + currWindow) / limit. Pros: Better than fixed window (reduces bursts). Less memory than sliding log. Cons: Approximation (not perfectly precise). Complex calculation. 4. Token Bucket: Bucket holds tokens (capacity = burst limit). Tokens added at fixed rate (refill rate = sustained rate). Each request consumes one token. Example: Bucket capacity 100, refill 10 tokens/second. Can burst 100 requests immediately, then 10/sec sustained. Pros: Allows bursts (smooth traffic spikes). Simple and efficient. Cons: Requires tracking bucket state (tokens, last refill time). 5. Leaky Bucket: Requests enter queue (bucket). Requests processed at constant rate (leak rate). Queue has max size (bucket capacity). Pros: Smooths bursty traffic. Constant outgoing rate. Cons: Requests delayed (queued), not rejected immediately. Memory for queue. Choosing algorithm: Fixed window: Simple APIs with rough limits. Sliding window: Precise rate limiting (fintech, critical APIs). Token bucket: APIs allowing bursts (file uploads, batch operations). Leaky bucket: Message queues, background processing. This simulator lets you test different algorithms, seeing how each handles burst traffic and sustained load differently.

Standard rate limit headers: X-RateLimit-Limit: 100 or RateLimit-Limit: 100: Maximum requests allowed in window. X-RateLimit-Remaining: 45 or RateLimit-Remaining: 45: Requests left before hitting limit. X-RateLimit-Reset: 1640000000 or RateLimit-Reset: 1640000000: Unix timestamp (seconds since epoch) when limit resets. Convert to date: new Date(reset * 1000). Alternative: RateLimit-Reset: 3600 (seconds until reset, not timestamp). Check API docs for format. Non-standard headers: Some APIs use different names: X-Rate-Limit-* (with hyphen), X-RateLimit-Reset-After (seconds until reset), X-RateLimit-Window (window size in seconds). 429 Too Many Requests response: Status code indicating rate limit exceeded. Headers: Retry-After: 60 (retry after 60 seconds) or Retry-After: Wed, 21 Oct 2015 07:28:00 GMT (absolute time). Body often includes error message: {"error": "Rate limit exceeded", "retryAfter": 60}. Handling rate limits in code: 1. Check headers proactively: const remaining = parseInt(response.headers.get('X-RateLimit-Remaining')); if (remaining < 10) { console.warn('Approaching rate limit'); }. 2. Pause when low: If remaining < threshold, slow down requests. 3. Handle 429 gracefully: if (response.status === 429) { const retryAfter = response.headers.get('Retry-After'); await sleep(retryAfter * 1000); return retry(); }. 4. Exponential backoff: If Retry-After not provided: const delay = Math.min(1000 * 2 ** attempt, 60000); (1s, 2s, 4s, 8s, max 60s). 5. Circuit breaker: After N consecutive 429s, stop making requests for longer period. Prevents hammering API. Best practices: Always check for 429 status. Respect Retry-After header. Log rate limit hits for monitoring. Implement jitter in retries (random delay to avoid thundering herd). Show user-friendly messages ('Rate limit exceeded, retrying in 60 seconds...'). This simulator helps you test your 429 handling logic by simulating rate limit scenarios with realistic headers.

Exponential backoff: Retry strategy where wait time increases exponentially after each failure. Pattern: 1s, 2s, 4s, 8s, 16s, 32s... Why exponential: Linear backoff (1s, 2s, 3s, 4s) keeps pressure on failing service. Exponential gives service time to recover. Reduces retry storm when many clients retry simultaneously. Basic implementation: async function fetchWithRetry(url, maxRetries = 5) {\n for (let attempt = 0; attempt < maxRetries; attempt++) {\n try {\n const response = await fetch(url);\n if (response.ok) return response;\n if (response.status === 429) {\n const delay = Math.pow(2, attempt) * 1000; // 1s, 2s, 4s, 8s, 16s\n await sleep(delay);\n continue;\n }\n throw new Error('Non-retryable error');\n } catch (error) {\n if (attempt === maxRetries - 1) throw error;\n }\n }\n}. Improvements: 1. Max delay cap: const delay = Math.min(Math.pow(2, attempt) * 1000, 60000); (cap at 60s to avoid extremely long waits). 2. Jitter (randomness): const jitter = Math.random() * 1000; const delay = Math.pow(2, attempt) * 1000 + jitter;. Prevents synchronized retries from multiple clients (thundering herd). Spreads load more evenly. 3. Full jitter: const delay = Math.random() * Math.pow(2, attempt) * 1000; (random between 0 and exponential delay). 4. Respect Retry-After header: if (response.headers.has('Retry-After')) {\n const retryAfter = parseInt(response.headers.get('Retry-After'));\n await sleep(retryAfter * 1000);\n continue;\n}. Server knows its state better than client's exponential guess. 5. Retryable vs non-retryable errors: Retry: 429 (rate limit), 500 (server error), 502 (bad gateway), 503 (service unavailable), 504 (timeout), network errors. Don't retry: 400 (bad request), 401 (unauthorized), 403 (forbidden), 404 (not found). Production-ready library: Use axios-retry, retry (npm packages) instead of rolling your own. Example: axiosRetry(axios, { retries: 5, retryDelay: axiosRetry.exponentialDelay });. Testing: Use this simulator to create scenarios where first N requests fail with 429, then succeed. Verify your backoff logic waits appropriate times. Check jitter spreads retries.

Local simulation: Use this Rate Limiter Simulator to create controlled rate limit scenarios. Configure: requests per second, window size, algorithm type. Test: How app behaves when limit hit. Whether retry logic works. If user sees appropriate messages. Mock API with rate limiting: Set up local mock server with rate limiting. MSW (Mock Service Worker): let requestCount = 0;\nconst resetTime = Date.now() + 60000;\nrest.get('/api/data', (req, res, ctx) => {\n requestCount++;\n if (requestCount > 10) {\n return res(\n ctx.status(429),\n ctx.set('X-RateLimit-Limit', '10'),\n ctx.set('X-RateLimit-Remaining', '0'),\n ctx.set('Retry-After', '60')\n );\n }\n return res(ctx.json({data: 'success'}));\n});. json-server with middleware: Add rate limiting to json-server for realistic local API. Testing scenarios: 1. Gradual limit approach: Make requests until X-RateLimit-Remaining approaches 0. Verify app slows down or warns user. 2. Hard limit hit: Exceed limit, get 429. Verify: Error handled gracefully. Retry-After respected. User sees clear message. Requests eventually succeed after reset. 3. Burst traffic: Send many requests rapidly. With token bucket, first N succeed (burst), then rate limited. With fixed window, all succeed until window limit. 4. Sustained traffic: Send requests at steady rate (just below limit). Should never hit limit. 5. Recovery after limit: After 429, wait for reset. Verify requests succeed again. Monitoring in development: Log all rate limit headers: console.log('Limit:', headers.get('X-RateLimit-Limit'));\nconsole.log('Remaining:', headers.get('X-RateLimit-Remaining'));\nconsole.log('Reset:', new Date(headers.get('X-RateLimit-Reset') * 1000));. Alert when remaining < threshold. Track 429 responses in analytics. Staging environment testing: Use production-like rate limits in staging. Load test to verify handling under realistic limits. Production monitoring: Track 429 rate in metrics (% of requests rate limited). Alert on sudden spikes (may indicate bug or attack). Monitor Retry-After delays (long delays impact UX). Load testing tools: Use k6, JMeter, or Artillery to generate load. Configure to respect rate limits (or intentionally exceed for testing). Best practices: Test all rate limit scenarios before production. Document expected behavior for each scenario. Add monitoring/alerting for rate limit events. Have fallback strategies (cached data, degraded functionality). Use this simulator during development to validate logic, then test with real API in staging before production deployment.

1. Request pooling/batching: Combine multiple operations into single request when possible. Batch API: POST /api/users/batch with array of users instead of individual POST /api/users for each. Reduces request count. GraphQL: Fetch multiple resources in one query instead of separate REST endpoints. 2. Caching: Cache responses to reduce redundant requests. HTTP caching: Respect Cache-Control headers, use ETag/conditional requests (If-None-Match). Client-side caching: Store responses in memory/localStorage. Set TTL based on data freshness requirements. Example: const cache = new Map();\nif (cache.has(url) && Date.now() < cache.get(url).expiry) {\n return cache.get(url).data;\n}. 3. Request throttling: Limit request rate on client side, stay below API limit. Token bucket implementation: class RateLimiter {\n constructor(rate) {\n this.tokens = rate;\n this.rate = rate;\n setInterval(() => {\n this.tokens = Math.min(this.tokens + 1, this.rate);\n }, 1000 / rate);\n }\n async execute(fn) {\n while (this.tokens < 1) {\n await sleep(100);\n }\n this.tokens--;\n return fn();\n }\n}. Libraries: bottleneck, p-limit (npm packages) for request queuing. 4. Queue management: Queue requests when rate limit approached. Process queue at sustainable rate. Example: const queue = []; setInterval(() => { if (queue.length > 0 && tokensAvailable) { processRequest(queue.shift()); } }, 1000);. 5. Graceful degradation: When rate limited, show cached/stale data with indicator. Disable non-critical features. Show friendly message: 'Temporarily limited, retrying...' 6. User communication: Display rate limit status: 'API calls: 45/100 remaining'. Show countdown when waiting for retry: 'Retrying in 30 seconds...' Let user cancel/pause requests. 7. Distributed systems considerations: With multiple servers/workers, coordinate to avoid exceeding shared limit. Use centralized rate limit tracking (Redis): INCR api:requests:user123, EXPIRE api:requests:user123 60. 8. Different limits per tier: Track user's API tier (free/paid/enterprise). Apply appropriate limits: const limit = user.tier === 'free' ? 100 : 10000;. 9. Monitoring and alerts: Alert developers when approaching limit (90% of remaining). Log all 429 responses for analysis. Track request patterns to optimize. 10. Testing: Use this simulator to test edge cases. Verify behavior at exactly the limit. Test recovery after 429. Ensure no request loops (retry logic doesn't create infinite retries). Architecture example: API client wrapper with built-in rate limiting, caching, and retry logic. Transparent to application code (developers call api.getUsers(), wrapper handles rate limiting).