This lesson's interactive features are locked, please to keep using them

Rate Limiting

Rate limiting sets a maximum number of requests within a time window. For example, you might allow each customer to generate five reports per minute.

Once the limit is hit, reject new requests with 429 Too Many Requests and a Retry-After header. If you've ever used an AI provider, you've probably seen these... a lot.

Failing intentionally with an error message is much better than letting the server actually run out of resources and crash.

Choosing a Limiter Key

Rate limits are applied based on who is making the request:

User ID – usually the best option for authenticated endpoints
API key – great for machine-to-machine APIs
IP address – useful before authentication, but shared networks can cause false positives

Rate limiting is most effective at the CDN, load balancer, or in middleware that runs before your expensive application logic. The earlier you block abuse, the less it costs you.

Assignment

The public product API is cheap to call repeatedly and useful to scrapers.

Add an endpoint-specific rate limit to /api/products.

Create another rate limiter configured for 30 requests per minute.
Mount it on /api/products before the existing CORS and router middleware. Preserve normal API responses and public CORS behavior.
Start the app.

With Bearly Secure still running, run and submit the CLI tests from the project root.