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 a stricter endpoint-specific limit without changing its normal responses or public CORS policy.

In internal/httpserver/app.go, create another fixedWindowRateLimiter allowing 30 requests per client IP per minute.
Use the trusted-proxy-aware client IP key and return a JSON 429 Too Many Requests response when limited.
Apply the limiter only to GET /api/products, preserving its normal response and Access-Control-Allow-Origin: * behavior.
Start the app.

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