Rate limiting in Laravel - Step-by-Step Execution

Concept Flow - Rate limiting

Request Received

↓

Check Rate Limit

↓

Reject

↓

Send 429

↓

Update Count

When a request comes in, Laravel checks if the user has exceeded the allowed number of requests. If yes, it rejects with a 429 error. Otherwise, it processes the request and updates the count.

Execution Sample

Laravel

Route::middleware('throttle:3,1')->get('/api/data', function () {
    return response()->json(['message' => 'Success']);
});

This code limits the API route to 3 requests per 1 minute per user.

Execution Table

Request Number	Requests in Last Minute	Condition (< 3?)	Action	Response
1	0	Yes	Allow and count request	200 Success
2	1	Yes	Allow and count request	200 Success
3	2	Yes	Allow and count request	200 Success
4	3	No	Reject request	429 Too Many Requests
5	3	No	Reject request	429 Too Many Requests
After 1 minute passes	0	Yes	Allow and reset count	200 Success

💡 Requests exceeding 3 in 1 minute are rejected with 429 error until time window resets.

Variable Tracker

Variable	Start	After Req 1	After Req 2	After Req 3	After Req 4	After 1 min
requests_count	0	1	2	3	3	0

Key Moments - 2 Insights

Why does the 4th request get rejected even though it is close in time to the 3rd?

Because the limit is 3 requests per 1 minute, the 4th request exceeds this limit as shown in execution_table row 4, so Laravel rejects it with a 429 response.

What happens to the request count after 1 minute?

After 1 minute, the count resets to 0 as shown in variable_tracker and execution_table row 6, allowing new requests to be accepted again.

Visual Quiz - 3 Questions

Look at the execution table, what is the response for the 3rd request?

A 429 Too Many Requests

B 500 Server Error

C 200 Success

D 404 Not Found

💡 Hint

Check the 'Response' column for Request Number 3 in the execution_table.

At which request number does the condition 'Requests in Last Minute < 3' become false?

A Request 2

B Request 4

C Request 3

D Request 5

💡 Hint

Look at the 'Condition' column in the execution_table to find when it changes to 'No'.

If the limit was changed to 5 requests per minute, how would the response for Request 4 change?

A It would be 200 Success

B It would be 429 Too Many Requests

C It would be 404 Not Found

D It would be 500 Server Error

💡 Hint

Consider the 'requests_count' variable and the new limit compared to execution_table rows.

Concept Snapshot

Laravel Rate Limiting:
- Use 'throttle:X,Y' middleware to limit X requests per Y minutes.
- Requests exceeding limit get 429 error.
- Count resets after time window.
- Helps protect APIs from overload.
- Easy to apply on routes or controllers.

Full Transcript

Rate limiting in Laravel controls how many requests a user can make in a set time. When a request arrives, Laravel checks if the user has made too many requests recently. If the user is within the limit, the request is allowed and counted. If the user exceeds the limit, Laravel rejects the request with a 429 Too Many Requests error. The count resets after the time window passes, allowing new requests. This protects your app from too many requests at once. The example code uses 'throttle:3,1' to allow 3 requests per 1 minute. The execution table shows requests 1 to 3 succeed, request 4 and 5 are rejected, and after 1 minute the count resets and requests succeed again.

Practice

1. What is the main purpose of rate limiting in Laravel applications?

easy

A. To speed up database queries automatically

B. To generate API tokens for users

C. To encrypt user passwords securely

D. To control how often users can make requests to keep the app stable

Solution

1. Step 1: Understand the concept of rate limiting

   Rate limiting is used to limit the number of requests a user can make in a given time to prevent overload.

2. Step 2: Identify the purpose in Laravel context

   Laravel uses rate limiting to keep the app stable by controlling request frequency.

3. Final Answer:

   To control how often users can make requests to keep the app stable -> Option D

4. Quick Check:

   Rate limiting = control request frequency [OK]

Hint: Rate limiting controls request frequency to protect apps [OK]

Common Mistakes:

• Confusing rate limiting with database optimization
• Thinking it encrypts data
• Assuming it generates tokens

2. Which of the following is the correct way to define a rate limiter in Laravel using RateLimiter::for?

easy

A. RateLimiter::limit('api', 60);

B. RateLimiter::for('api', fn (Request $request) => Limit::perMinute(60));

C. RateLimiter::set('api', 60);

D. RateLimiter::create('api', 60);

Solution

1. Step 1: Recall Laravel rate limiter syntax

   Laravel uses RateLimiter::for with a closure returning a Limit object.

2. Step 2: Match the correct syntax

   RateLimiter::for('api', fn (Request $request) => Limit::perMinute(60)); correctly uses RateLimiter::for with a closure and Limit::perMinute(60).

3. Final Answer:

   RateLimiter::for('api', fn (Request $request) => Limit::perMinute(60)); -> Option B

4. Quick Check:

   Correct syntax uses RateLimiter::for + Limit::perMinute [OK]

Hint: Use RateLimiter::for with a closure returning Limit [OK]

Common Mistakes:

• Using non-existent methods like set or create
• Passing number directly without Limit::perMinute
• Missing the closure function

3. Given this route definition in Laravel:

Route::middleware('throttle:api')->get('/data', function () { return 'OK'; });

If the rate limiter 'api' allows 2 requests per minute, what will happen on the 3rd request within the same minute?

medium

A. The request will be blocked with a 429 Too Many Requests response

B. The request will succeed and return 'OK'

C. The request will cause a server error 500

D. The request will be queued and delayed

Solution

1. Step 1: Understand the throttle middleware behavior

   The throttle middleware limits requests based on the named limiter, here 'api'.

2. Step 2: Apply the limit of 2 requests per minute

   After 2 requests, the 3rd request exceeds the limit and is blocked with a 429 error.

3. Final Answer:

   The request will be blocked with a 429 Too Many Requests response -> Option A

4. Quick Check:

   Exceed limit = 429 error [OK]

Hint: Requests over limit get 429 error response [OK]

Common Mistakes:

• Assuming requests always succeed
• Thinking server error 500 occurs
• Believing requests get queued automatically

4. Consider this Laravel rate limiter definition:

RateLimiter::for('login', function (Request $request) { return Limit::perMinute(5)->by($request->ip()); });

What is wrong if users report they can make unlimited login attempts?

medium

A. The RateLimiter::for method is deprecated

B. The Limit::perMinute(5) should be Limit::perSecond(5)

C. The limiter is not applied on the login route middleware

D. The by() method should use user ID instead of IP

Solution

1. Step 1: Check if limiter is applied on route

   Defining a limiter alone does not enforce it; middleware must use 'throttle:login'.

2. Step 2: Identify missing middleware usage

   If middleware is missing on login route, rate limiting won't work, allowing unlimited attempts.

3. Final Answer:

   The limiter is not applied on the login route middleware -> Option C

4. Quick Check:

   Limiter defined but not applied = no limit [OK]

Hint: Define limiter and apply middleware to enforce it [OK]

Common Mistakes:

• Thinking perSecond is required instead of perMinute
• Assuming by() must use user ID always
• Believing RateLimiter::for is deprecated

5. You want to create a rate limiter in Laravel that allows 10 requests per minute per user, but if the user is an admin, allow 100 requests per minute. Which code correctly implements this?

hard

A. RateLimiter::for('custom', function (Request $request) { return $request->user()?->isAdmin() ? Limit::perMinute(100)->by($request->user()->id) : Limit::perMinute(10)->by($request->user()->id); });

B. RateLimiter::for('custom', fn(Request $request) => Limit::perMinute(10));

C. RateLimiter::for('custom', function (Request $request) { if ($request->user()->isAdmin()) { return Limit::perMinute(10); } else { return Limit::perMinute(100); } });

D. RateLimiter::for('custom', fn(Request $request) => Limit::perMinute($request->user()->isAdmin() ? 10 : 100));

Solution

1. Step 1: Check conditional logic for admin and normal users

   Admins get 100 requests/min, others get 10 requests/min, keyed by user ID.

2. Step 2: Verify correct use of ternary and by() method

   RateLimiter::for('custom', function (Request $request) { return $request->user()?->isAdmin() ? Limit::perMinute(100)->by($request->user()->id) : Limit::perMinute(10)->by($request->user()->id); }); uses ternary to select limit and keys by user ID, handling null user safely.

3. Final Answer:

   RateLimiter::for('custom', function (Request $request) { return $request->user()?->isAdmin() ? Limit::perMinute(100)->by($request->user()->id) : Limit::perMinute(10)->by($request->user()->id); }); -> Option A

4. Quick Check:

   Conditional limits with by(user ID) = RateLimiter::for('custom', function (Request $request) { return $request->user()?->isAdmin() ? Limit::perMinute(100)->by($request->user()->id) : Limit::perMinute(10)->by($request->user()->id); }); [OK]

Hint: Use ternary inside RateLimiter::for with by(user id) [OK]

Common Mistakes:

• Swapping admin and user limits
• Not keying limits by user ID
• Using wrong ternary logic or missing by()