Throttling APIs
Overview
Implement API throttling policies that protect backend services from overload by controlling request concurrency, queue depth, and processing rates. Apply backpressure mechanisms including concurrent request limits, priority queues, circuit breakers, and adaptive throttling that adjusts limits based on real-time backend health metrics.
Prerequisites
- Middleware-capable web framework (Express, FastAPI, Spring Boot, Gin)
- Redis or in-memory store for distributed throttle state tracking
- Monitoring system exposing backend latency and error rate metrics (Prometheus, CloudWatch)
- Load testing tool (k6, Artillery, wrk) for validating throttle behavior under pressure
- Queue system for request buffering during throttle events (optional: Bull, SQS)
Instructions
- Analyze existing route handlers and middleware using Grep and Read to identify endpoints with high latency, database-heavy operations, or external service dependencies that need throttle protection.
- Implement a concurrency limiter middleware that tracks in-flight requests per endpoint and rejects new requests with 503 Service Unavailable when the concurrent limit is reached.
- Add priority queue support that classifies requests by API key tier (free, pro, enterprise) and serves higher-tier requests first when approaching throttle limits.
- Build a circuit breaker for downstream service calls that opens after configurable failure thresholds (e.g., 5 failures in 10 seconds), returning 503 with
Retry-After during the open state.
- Configure adaptive throttling that monitors backend response latency percentiles (p95, p99) and automatically reduces concurrency limits when latency exceeds SLO thresholds.
- Add throttle state headers to all responses:
X-Throttle-Limit, X-Throttle-Remaining, and X-Throttle-Reset for client-side awareness.
- Implement graceful degradation strategies per endpoint: serve cached responses, return partial results, or queue requests for deferred processing.
- Write load tests that verify throttle engagement at expected thresholds, proper 503 responses with
Retry-After, and recovery behavior when load subsides.
See ${CLAUDE_SKILL_DIR}/references/implementation.md for the full implementation guide.
Output
${CLAUDE_SKILL_DIR}/src/middleware/throttle.js - Concurrency and request rate throttling middleware${CLAUDE_SKILL_DIR}/src/middleware/circuit-breaker.js - Circuit breaker for downstream service protection${CLAUDE_SKILL_DIR}/src/middleware/priority-queue.js - Tier-based request prioritization${CLAUDE_SKILL_DIR}/src/config/throttle-config.js - Per-endpoint throttle policy definitions${CLAUDE_SKILL_DIR}/tests/throttle/ - Load tests validating throttle engagement and recovery
Error Handling
| Error |
Cause |
Solution |
| 503 Service Unavailable |
Concurrency limit reached for the endpoint |
Return Retry-After header with estimated wait time; include throttle state headers |
| 503 Circuit Open |
Circuit breaker tripped due to downstream failures |
Return cached response if available; provide circuit reset time in response body |
| Queue overflow |
Request buffer exceeded maximum depth |
Reject with 503; alert operations team; consider scaling backend capacity |
| Stale throttle state |
Redis connection lost; throttle counters become inaccurate |
Fall back to in-process counters; reconnect with backoff; log state inconsistency |
| Priority starvation |
Low-tier requests never served under sustained high-tier load |
Reserve minimum throughput percentage for each tier to prevent complete starvation |
Refer to ${CLAUDE_SKILL_DIR}/references/errors.md for comprehensive error patterns.
Examples
Database-heavy endpoint protection: Apply concurrency limit of 10 to a report generation endpoint that runs expensive aggregation queries, queueing additional requests with estimated wait times.
Multi-tier SaaS throttling: Enterprise tier gets 100 concurrent requests, Pro tier gets 25, Free tier gets 5, with priority queue ensuring enterprise requests are served first during contention.
Adaptive autoscaling trigger: Throttle middleware emits metrics that trigger horizontal pod autoscaling when throttle engagement rate exceeds 20% sustained over 5 minutes.
See ${CLAUDE_SKILL_DIR}/references/examples.md for additional examples.
Resources
- Circuit Breaker pattern: Martin Fowler's design patterns
- Resilience4j (Java) and cockatiel (Node.js) circuit breaker libraries
- Netflix Concurrency Limits library for adaptive throttling
- Token bucket and leaky bucket algorithm implementations
1---2name: throttling-apis3description: Implement API throttling policies to protect backend services from overload. Use when controlling API request rates. Trigger with phrases like "throttle API", "control request rate", or "add throttling".4license: MIT5---6# Throttling APIs
7
8## Overview
9
10Implement API throttling policies that protect backend services from overload by controlling request concurrency, queue depth, and processing rates. Apply backpressure mechanisms including concurrent request limits, priority queues, circuit breakers, and adaptive throttling that adjusts limits based on real-time backend health metrics.
11
12## Prerequisites
13
14- Middleware-capable web framework (Express, FastAPI, Spring Boot, Gin)
15- Redis or in-memory store for distributed throttle state tracking
16- Monitoring system exposing backend latency and error rate metrics (Prometheus, CloudWatch)
17- Load testing tool (k6, Artillery, wrk) for validating throttle behavior under pressure
18- Queue system for request buffering during throttle events (optional: Bull, SQS)
19
20## Instructions
21
221. Analyze existing route handlers and middleware using Grep and Read to identify endpoints with high latency, database-heavy operations, or external service dependencies that need throttle protection.
232. Implement a concurrency limiter middleware that tracks in-flight requests per endpoint and rejects new requests with 503 Service Unavailable when the concurrent limit is reached.
243. Add priority queue support that classifies requests by API key tier (free, pro, enterprise) and serves higher-tier requests first when approaching throttle limits.
254. Build a circuit breaker for downstream service calls that opens after configurable failure thresholds (e.g., 5 failures in 10 seconds), returning 503 with `Retry-After` during the open state.
265. Configure adaptive throttling that monitors backend response latency percentiles (p95, p99) and automatically reduces concurrency limits when latency exceeds SLO thresholds.
276. Add throttle state headers to all responses: `X-Throttle-Limit`, `X-Throttle-Remaining`, and `X-Throttle-Reset` for client-side awareness.
287. Implement graceful degradation strategies per endpoint: serve cached responses, return partial results, or queue requests for deferred processing.
298. Write load tests that verify throttle engagement at expected thresholds, proper 503 responses with `Retry-After`, and recovery behavior when load subsides.
30
31See `${CLAUDE_SKILL_DIR}/references/implementation.md` for the full implementation guide.
32
33## Output
34
35- `${CLAUDE_SKILL_DIR}/src/middleware/throttle.js` - Concurrency and request rate throttling middleware
36- `${CLAUDE_SKILL_DIR}/src/middleware/circuit-breaker.js` - Circuit breaker for downstream service protection
37- `${CLAUDE_SKILL_DIR}/src/middleware/priority-queue.js` - Tier-based request prioritization
38- `${CLAUDE_SKILL_DIR}/src/config/throttle-config.js` - Per-endpoint throttle policy definitions
39- `${CLAUDE_SKILL_DIR}/tests/throttle/` - Load tests validating throttle engagement and recovery
40
41## Error Handling
42
43| Error | Cause | Solution |
44|-------|-------|----------|
45| 503 Service Unavailable | Concurrency limit reached for the endpoint | Return `Retry-After` header with estimated wait time; include throttle state headers |
46| 503 Circuit Open | Circuit breaker tripped due to downstream failures | Return cached response if available; provide circuit reset time in response body |
47| Queue overflow | Request buffer exceeded maximum depth | Reject with 503; alert operations team; consider scaling backend capacity |
48| Stale throttle state | Redis connection lost; throttle counters become inaccurate | Fall back to in-process counters; reconnect with backoff; log state inconsistency |
49| Priority starvation | Low-tier requests never served under sustained high-tier load | Reserve minimum throughput percentage for each tier to prevent complete starvation |
50
51Refer to `${CLAUDE_SKILL_DIR}/references/errors.md` for comprehensive error patterns.
52
53## Examples
54
55**Database-heavy endpoint protection**: Apply concurrency limit of 10 to a report generation endpoint that runs expensive aggregation queries, queueing additional requests with estimated wait times.
56
57**Multi-tier SaaS throttling**: Enterprise tier gets 100 concurrent requests, Pro tier gets 25, Free tier gets 5, with priority queue ensuring enterprise requests are served first during contention.
58
59**Adaptive autoscaling trigger**: Throttle middleware emits metrics that trigger horizontal pod autoscaling when throttle engagement rate exceeds 20% sustained over 5 minutes.
60
61See `${CLAUDE_SKILL_DIR}/references/examples.md` for additional examples.
62
63## Resources
64
65- Circuit Breaker pattern: Martin Fowler's design patterns
66- Resilience4j (Java) and cockatiel (Node.js) circuit breaker libraries
67- Netflix Concurrency Limits library for adaptive throttling
68- Token bucket and leaky bucket algorithm implementations
micsapp