Transcript

Rate limiting is a strategy used in back end systems to control how much traffic a service handles. It protects against abuse, prevents resource exhaustion, and ensures fair access to all users. It's how we keep systems stable, fair, and fast. There are four major strategies to rate limiting, and each one handles traffic differently. The first approach is the fixed window. It's the simplest form of rate limiting. You choose a time window, say one minute for example, and then set a limit like 100 requests per minute every time a request from a specific client comes in. You increase that client's counter. When the minute resets, the counter goes back to zero, given the client another 100 requests for the next minute. It's easy to understand, easy to implement, and very fast. But here's the problem. The fixed window doesn't care when the request arrives inside the window. So a client can send 100 requests at 115959, then another hundred at 12. That's 200 request in two seconds, even though the limit is 100 per minute. This creates an attack pattern called burstiness, which is technically legal, but can be annoying to deal with. This burstiness is exactly where we move to the next approach, the sliding window. Instead of resetting counters at fixed intervals, the sliding window calculates usage over the past time period from the moment each request arrives. So if your limit is 100 requests per minute, every time a new request comes in, it looks back at the past 60 seconds to see how many requests were made and checks if the limit has been reached. But sliding windows aren't perfect either. You can still get microburst. Depending on how you track time buckets, you user can squeeze in a spike in traffic. Still passes the limits. These limitations lead us to a different class of algorithms that handle burstiness more naturally. Instead of counting how many requests you've made, what if we give clients a budget to spend? That's the token bucket approach. You fill a bucket assigned to a client with tokens at a steady rate, say 10 tokens per second. Each request consumes A token. A request that requires multiple operations may cost multiple tokens. If a request comes in and you have tokens, you're good. But if the bucket is empty, the service. Has reached its limit. The key advantage is that the token bucket allows controlled bursts. The bucket can hold extra tokens, so if a client sends requests in spikes, that's allowed as long as the bucket hasn't been drained already and they're tokens in it. But for situations that require strict predictable traffic flow, token bucket might be too lenient. That's where the leaky bucket comes in. In the leaky bucket, new requests flow into the bucket and are processed at a fixed rate. Think of it like a bucket with a hole in the bottom. A lot of requests can enter the bucket from the top, but the only. Exist through the hole at the bottom at a fixed steady pace. If request come in faster than they can drain out of the bucket, the bucket overflows and those extra requests get dropped. The leaky bucket gives the most predictable, smooth traffic pattern. It enforces consistency, which is great for systems that get overwhelmed easily and need guaranteed steady throughput. But the drawback is that it's the least flexible. Most production systems use a combination of these strategies. Although Marcos from programming videos like this and check out umacodes.com for more.