Rate limiting in Ruby on Rails - Step-by-Step Execution

Concept Flow - Rate limiting

Request Received

↓

Check Rate Limit

↓

Reject

↓

Send 429

↓

Update Count

↓

End

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

Execution Sample

Ruby on Rails

class ApplicationController < ActionController::Base
  before_action :check_rate_limit

  def check_rate_limit
    key = "user:#{request.ip}:requests"
    count = Rails.cache.read(key) || 0
    if count >= 5
      render plain: "Rate limit exceeded", status: 429
    else
      Rails.cache.write(key, count + 1, expires_in: 1.minute)
    end
  end
end

This code limits each IP to 5 requests per minute, rejecting requests beyond that with a 429 error.

Execution Table

Step	Request #	Cache Read (count)	Condition (count >= 5)	Action	Response
1	1	0	False	Increment count to 1	Allow request
2	2	1	False	Increment count to 2	Allow request
3	3	2	False	Increment count to 3	Allow request
4	4	3	False	Increment count to 4	Allow request
5	5	4	False	Increment count to 5	Allow request
6	6	5	True	Reject request	429 Rate limit exceeded
7	7	5	True	Reject request	429 Rate limit exceeded
Exit	-	-	-	-	Requests blocked after 5 allowed in 1 minute

💡 After 5 requests, count reaches 5 and condition becomes true, so further requests are rejected.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	After 6	Final
count	0	1	2	3	4	5	5	5
request #	N/A	1	2	3	4	5	6	7

Key Moments - 2 Insights

Why does the count stay at 5 after the 6th request instead of increasing?

Because the condition count >= 5 is true at step 6, the request is rejected and the count is not incremented, as shown in execution_table rows 6 and 7.

What happens if the cache expires after 1 minute?

The count resets to 0 because the cache key expires, allowing new requests to be counted fresh, restarting the rate limit window.

Visual Quiz - 3 Questions

Look at the execution table, what is the count value read from cache at request #4?

A 3

B 4

C 2

D 5

💡 Hint

Check the 'Cache Read (count)' column at Step 4 in the execution_table.

At which request number does the condition count >= 5 become true?

A 5

B 6

C 4

D 7

💡 Hint

Look at the 'Condition (count >= 5)' column in the execution_table to find when it first becomes true.

If the limit was changed to 3 requests per minute, what would happen at request #4?

A Request #4 allowed, count increments to 4

B Request #4 allowed, count resets to 1

C Request #4 rejected with 429 error

D Request #4 ignored

💡 Hint

Refer to how condition triggers rejection when count reaches the limit in execution_table.

Concept Snapshot

Rate limiting in Rails:
Use a before_action to check request count.
Store count in cache with expiration (e.g., 1 minute).
If count >= limit, reject with 429 status.
Else increment count and allow request.
Prevents too many requests in short time.

Full Transcript

Rate limiting in Rails works by counting how many requests come from a user or IP in a set time. When a request arrives, the system reads the current count from cache. If the count is less than the limit, it increases the count and lets the request continue. If the count reaches or exceeds the limit, the system rejects the request with a 429 error, telling the user to slow down. The count resets after the cache expires, usually after a minute. This helps protect the app from too many requests at once.