Server-side vs client-side throttling
Throttling happens on both ends. The server throttles you: it sets rate-limit rules - caps on how many requests it will accept in a given time window, counted per IP address, per URL, or per account - and once you cross the line it replies with a 429 (too many requests) or 503 (service unavailable). Your scraper throttles itself: it limits how many requests it sends at once and spaces them out, so it stays below those limits before the server ever has to push back. Good scraping is mostly the second kind - you pace yourself so the server never needs to.
Why throttling matters for scraping
Blasting a site with rapid-fire requests is one of the loudest bot signals there is. It triggers soft blocks (429s), and if you keep pushing those escalate into hard bans on your IP address. Respecting the limits - obeying the Retry-After header (the server's hint for how long to wait before trying again) and slowing down when you see 429s - keeps your access steady and your IPs in good standing. Throttling is the difference between a scraper that runs for months and one that's banned in an hour.
How to throttle a scraper correctly
Pick a sensible limit on how many requests run at the same time, add small random delays between requests (jitter, so your timing doesn't look robotically uniform), and use exponential backoff when you hit a 429 - wait a bit, then double the wait each time it happens again. Then spread the load across rotating proxies so each individual IP stays at a human pace even as your total volume goes up. If you'd rather not tune all of this by hand, a web scraping API handles request pacing, proxy rotation, and retries for you.