Course outline · 0% complete

0/29 lessons0%

Course overview →

Rate Limiting

lesson 8-3 · ~12 min · 26/29

Why servers say "slow down"

Without limits, one client can hammer your API: a password-guessing bot on /login (the attack lesson 7-4 warned about), a buggy script in a retry loop, or a scraper pulling your whole database. Each request costs you CPU, database load, and money.

A rate limiter counts requests per client (usually per IP address or per user) inside a time window and rejects the excess with status 429 Too Many Requests (from the lesson 3-3 table).

The simplest scheme is the fixed window: allow at most N requests per minute, reset the counts when the next minute starts. The core is just a Map of counters, which is exactly what you will build, minus the clock so the output stays deterministic.

window 1 (limit 3)window 2 (counts reset)200200200429200200
Fixed-window limiting with limit 3: the fourth request in a window is rejected with 429, and a fresh window starts the count over.

Code exercise · javascript

Your turn. Complete allow(ip): read the current count for that ip (0 if absent), return false when the limit is already used up, otherwise increment and return true. The test simulates one noisy client and one normal one.

Code exercise · javascript

Your turn, part two. A FIXED window means the counters are wiped when a new time window starts. allow is already solved; add reset(), which clears every counter with counts.clear(). The test blocks a noisy client, resets (as if the next minute began), and the client is welcome again.

Quiz

Your limiter's counts live in a Map inside one Node process. You scale to 3 servers behind a load balancer (a machine that spreads incoming requests across your servers). What happens to the limit?