Bandwidth throttling

Throttling caps throughput: bytes per second to a given client, connection, or file. That is a different lever from request rate limiting, which counts requests per minute. One person hammering your API 500 times a second is a rate-limit problem; one person pulling a 4 GB video file at full speed while everyone else waits is a bandwidth problem. Most implementations use a token bucket: a steady refill rate plus a burst allowance, so small requests feel instant and long transfers settle to the cap.

Reach for it when bandwidth is the scarce resource or the metered cost: large file and video downloads, backup or export endpoints, free tiers that get a slower ceiling than paid ones, and shared origins where one greedy client starves the rest. Nginx does it with 'limit_rate'. CDNs mostly do not: they will rate limit requests all day, but an arbitrary byte-per-second cap is rare and tends to live in a provider-specific media or streaming product, so the throttle usually belongs in your origin, your reverse proxy, or the application's own response stream. Cloud egress pricing is usually why someone goes looking for the setting in the first place.

Gotcha: the word means two unrelated things and people talk past each other constantly. There is the server-side cap above, and there is the developer flavor: Chrome DevTools 'Slow 4G' network throttling, which only fakes conditions in your own browser and protects nothing. Second trap: throttling a progressive video or streamed response too close to its actual bitrate produces constant rebuffering, which reads to users as a broken player rather than a policy.