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

Throttling Requests

Throttling and rate limiting are often used interchangeably... but when we get super picky about definitions, they're a bit different.

Rate limiting is a per-client allowance
Throttling is a shared processing ceiling for an expensive operation

Throttling is useful when expensive work or a fragile downstream system can saturate under traffic spikes. For example, on Boot.dev we generate preview images for profile pages, but if 1000 users all request a new image at the same time, our image service throttles the requests to avoid becoming overwhelmed.

Shared Throttle

Imagine a report generation service that's only allowed to start five jobs per second across all clients. Rotating IP addresses doesn't help an attacker because everyone shares the same ceiling.

Rejected requests should get 429 Too Many Requests with a Retry-After header so clients know when to try again.

Assignment

Product search is Bearly Secure's expensive public query surface.

Add a shared throttle to GET /search.

createRateLimiter already tracks requests and adds the standard rate-limit and Retry-After headers. Configure one limiter, then pass it to the search route before its existing handler.

In src/routes/storefront.ts, create a search throttle:
1. 5 requests per second.
2. Use a constant key so every caller shares one counter. Rotating client IPs must not bypass the ceiling.
3. When the throttle rejects a request, send a 429 Too Many Requests error page telling them to try again soon.
Add the throttle to GET /search before the existing handler.
Start the app.

This in-memory throttle creates one shared ceiling per Bearly Secure process. A multi-instance production deployment needs a shared limiter at the edge or in a shared store.

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