No doubt you're already familiar with Laravel's rate limiting capabilities. In my AppServiceProvider I've set up a rate limiter for our API, where I check if the User is on a paid plan, and if so I'm going to allow them to have 1000 requests per minute, but if they're on the free plan, they're only allowed 10. Why don't we go ahead and jump into that app.php bootstrap file, and in with middleware we'll apply it to every API route by saying middleware('api', 'throttle:api') like so. That's pretty neat. I've created a little scratch file that's essentially going to make a call request to our API, currently we're using a User on the free plan, and we'll make 1000 requests, and of course I'll log the number of successes based on the HTTP status code that's returned.

our API, currently we're using a User on the free plan, and we'll make 1000 requests, and of course I'll log the number of successes based on the HTTP status code that's returned. Let's go ahead and run this for the free user. If our limiter works, I would expect 990 failures and 10 successes, it took 4.08 seconds, and yeah as we'd expect we made 10 successful requests, but 990 were blocked by the rate limiter. However, if we switch over to the User on the paid plan and re-run this script, I would expect that we had 0 failures. Here we go, yep 429 responses, 0, because of that higher rate limit. However, note that the User was still able to make 1000 requests in the space of 4.62

Here we go, yep 429 responses, 0, because of that higher rate limit. However, note that the user was still able to make 1000 requests in the space of 4.62 seconds. That means that we had to boot our application up 1000 times in 4.62 seconds, we hit the database at least 1000 times, but maybe 2000, 3000 times in 4.62 seconds, all for this one user who yes is allowed to make 1000 requests, but we likely never meant for them to make 1000 requests in such a small space of time. There hasn't really been a way to navigate this problem in previous versions of Laravel, but now with per second rate limiting, you have much more control over the flow. Let's head back to our rate limiter, and rather than returning a single limit here, I'm going

but now with per second rate limiting, you have much more control over the flow. Let's head back to our RateLimiter, and rather than returning a single limit here, I'm going to return an array of limits like so. Above the per minute rate limit, I'll introduce a per second rate limit, and why don't we set this to 20 requests. So yeah, they're allowed to make 1000 requests per minute, but every second they're only allowed to make 20 requests. So if we make sure we've cleared the cache so that all rate limiting is reset, and then we'll go back to our script and rerun, we should now see that maybe 30 or 40 requests actually go through for this paid user.

we'll go back to our script and rerun, we should now see that maybe 30 or 40 requests actually go through for this paid user. So yeah, here we go, they had 50 successful responses, but 950 of those responses returned a 429. Of course, if the user spreads out their requests over the minute rather than trying to execute them all within a few seconds, we will allow that. So why don't we update our script. I'll do something naive because this is only an example. We'll decrease the increment, and then why don't we sleep for one second. Let's rerun the script, and of course I'll skip forward because this will now take longer.

We'll decrease the increment, and then why don't we sleep for one second. Let's rerun the script, and of course I'll skip forward because this will now take longer than 4 seconds. Here we are, so not the most efficient fallback method, it took us 105 seconds, but note that we were able to make 1000 successful requests again because we spread out over the minute instead of trying to cram them all within that per second rate limiter. So keep Laravel 11's new per second rate limits in mind whenever you're trying to manage the flow of requests into your application. I will say that you shouldn't try to use this to prevent DDoS attacks, because whilst it will help a little, your application is still being hit, it's being booted up, it will take

I will say that you shouldn't try to use this to prevent DDoS attacks, because whilst it will help a little, your application is still being hit, it's being booted up, it will take time and it will slow down your server. Instead you should be looking at a service like Cloudflare or similar that will actually stand in the way of your users and your application. But if you're just trying to manage bottlenecks here and there from legitimate users with legitimate use cases, then per second rate limiting is going to help a great deal with that.