Rate limiting in Ruby on Rails - Deep Dive

Overview - Rate limiting

What is it?

Rate limiting is a way to control how many times a user or system can make requests to a server in a certain time. It helps prevent overload and abuse by limiting the speed of incoming requests. In Rails, rate limiting can be added to protect your app from too many requests that slow it down or cause errors. It works by counting requests and blocking or delaying extra ones when limits are reached.

Why it matters

Without rate limiting, a website or app can get overwhelmed by too many requests, either by accident or on purpose. This can make the app slow or crash, hurting users and business. Rate limiting keeps the app stable and fair by making sure no one uses too much of the server's power. It also helps stop attacks like spamming or trying to guess passwords quickly.

Where it fits

Before learning rate limiting, you should understand how web requests and responses work in Rails, including controllers and middleware. After mastering rate limiting, you can explore advanced security topics like authentication throttling, API key management, and distributed caching for scaling.

Mental Model

Core Idea

Rate limiting is like a traffic light that controls how many cars (requests) can pass through an intersection (server) in a given time to keep traffic flowing smoothly.

Think of it like...

Imagine a water faucet that only lets a certain amount of water flow per minute. If you try to open it more, the faucet slows or stops the flow to avoid flooding. Rate limiting works the same way for requests to a server.

┌───────────────┐
│ Incoming      │
│ Requests      │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Rate Limiter  │
│ (counts &     │
│  controls)    │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Server        │
│ Processes     │
│ Allowed       │
│ Requests      │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding web requests basics

Concept: Learn what a web request is and how Rails handles it.

When you visit a website or use an app, your browser sends a request to the server. Rails receives this request, processes it in a controller, and sends back a response like a webpage or data. Each request uses some server resources like memory and CPU.

Result

You know that every user action creates a request that the server must handle.

Understanding requests is key because rate limiting controls how many of these requests the server accepts.

2

Foundation

Why servers need protection

Concept: Servers can get overwhelmed if too many requests come at once.

If too many requests arrive quickly, the server might slow down or crash. This can happen by accident if many users visit at once or on purpose by attackers trying to overload the system. Protecting the server keeps the app reliable for everyone.

Result

You see why controlling request flow is important for app stability.

Knowing the risk of overload helps you appreciate why rate limiting is necessary.

3

Intermediate

Basic rate limiting strategies

🤔Before reading on: do you think rate limiting blocks requests immediately or delays them? Commit to your answer.

Concept: Rate limiting can block or delay requests based on rules like max requests per minute.

Common strategies include: - Fixed window: count requests in fixed time blocks (e.g., 100 per minute). - Sliding window: count requests in a moving time frame. - Token bucket: allow bursts but limit average rate. In Rails, middleware or gems can implement these strategies to check requests and respond with errors or wait times when limits are hit.

Result

You understand different ways to count and limit requests over time.

Knowing multiple strategies lets you choose the best fit for your app's needs.

4

Intermediate

Implementing rate limiting in Rails

🤔Before reading on: do you think rate limiting is best done in controllers or middleware? Commit to your answer.

Concept: Rails apps usually add rate limiting in middleware or use gems to handle it before requests reach controllers.

Middleware runs before controllers and can check request counts per user or IP. Popular gems like Rack::Attack let you define rules easily. For example, you can block IPs that send more than 5 requests per second or throttle login attempts. This keeps controllers clean and centralizes control.

Result

You can add rate limiting to your Rails app using middleware or gems.

Placing rate limiting early in the request flow improves performance and security.

5

Intermediate

Handling blocked requests gracefully

🤔Before reading on: do you think blocked requests should return a generic error or a specific message? Commit to your answer.

Concept: When requests exceed limits, the server should respond clearly and politely to users or clients.

Instead of crashing or ignoring extra requests, the server returns a 429 Too Many Requests status. You can customize the message or add headers telling when to try again. This helps users understand the problem and prevents confusion or frustration.

Result

Users get clear feedback when rate limits are hit.

Good communication improves user experience even when limiting access.

6

Advanced

Distributed rate limiting challenges

🤔Before reading on: do you think rate limiting works the same on one server and many servers? Commit to your answer.

Concept: When your app runs on multiple servers, rate limiting must share data across them to count requests correctly.

In a multi-server setup, each server sees only part of the traffic. To limit globally, you need a shared store like Redis to track counts. This adds complexity and potential delays but ensures fair limits. Rails apps often use Redis-backed stores with Rack::Attack for this purpose.

Result

You understand why distributed rate limiting needs shared storage.

Knowing this prevents bugs where limits are bypassed in multi-server environments.

7

Expert

Avoiding common pitfalls in production

🤔Before reading on: do you think aggressive rate limiting can block legitimate users? Commit to your answer.

Concept: Rate limiting must balance security and user experience to avoid blocking good users or causing outages.

Too strict limits can lock out real users, especially behind shared IPs or proxies. You should whitelist trusted clients, use adaptive limits, and monitor logs. Also, caching and efficient data stores reduce overhead. Experts tune limits based on traffic patterns and business needs.

Result

You can design rate limiting that protects without harming users.

Understanding tradeoffs helps build robust, user-friendly rate limiting in real apps.

Under the Hood

Rate limiting works by tracking each request's identity (like IP or user ID) and timestamp. The system stores counts in memory or fast databases like Redis. When a new request arrives, it checks if the count exceeds the limit in the time window. If yes, it blocks or delays the request. Middleware intercepts requests early to enforce these rules before reaching app logic.

Why designed this way?

Rate limiting was designed to protect servers from overload and abuse while keeping legitimate traffic flowing. Early web servers had no built-in limits, causing crashes under heavy load. Using middleware and external stores like Redis allows scalable, flexible limits without changing app code. Alternatives like blocking at firewalls exist but lack app-level control.

┌───────────────┐
│ Client sends  │
│ request       │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Middleware    │
│ checks count  │
│ in Redis      │
└──────┬────────┘
       │
  ┌────┴─────┐
  │          │
  ▼          ▼
Allow     Block with
request   429 response
  │          │
  ▼          ▼
App       Client sees
logic     error message

Myth Busters - 4 Common Misconceptions

Quick: Do you think rate limiting only blocks bad users? Commit to yes or no.

Common Belief: Rate limiting is only for stopping hackers or attackers.

Reality: Rate limiting also protects against accidental overload from normal users or buggy clients.

Why it matters: Ignoring normal traffic spikes can cause crashes even without attacks.

Quick: Do you think rate limiting can be done only in controllers? Commit to yes or no.

Common Belief: You can add rate limiting just by checking in controller actions.

Reality: Rate limiting works best in middleware before controllers to save resources and centralize control.

Why it matters: Doing it in controllers wastes server power and can miss some requests.

Quick: Do you think rate limiting is the same on single and multi-server apps? Commit to yes or no.

Common Belief: Rate limiting works the same regardless of how many servers run the app.

Reality: Distributed apps need shared storage like Redis to track requests across servers correctly.

Why it matters: Without shared tracking, limits can be bypassed, causing overload.

Quick: Do you think blocking all requests after limit is always best? Commit to yes or no.

Common Belief: Once the limit is hit, all extra requests should be blocked immediately.

Reality: Sometimes delaying or throttling requests is better to avoid user frustration and allow bursts.

Why it matters: Strict blocking can harm user experience and cause lost customers.

Expert Zone

1

Rate limiting should consider user identity beyond IP, like API keys or user accounts, to avoid unfair blocking.

2

Adaptive rate limits that change based on traffic patterns reduce false positives and improve usability.

3

Integrating rate limiting with monitoring and alerting helps detect attacks early and tune limits effectively.

When NOT to use

Rate limiting is not suitable for internal trusted services where high throughput is needed; instead, use authentication and authorization controls. For very high-scale APIs, consider API gateways or cloud provider rate limiting features that handle distributed limits more efficiently.

Production Patterns

In production Rails apps, rate limiting is often implemented with Rack::Attack using Redis as a store. Rules include throttling login attempts, API calls per user, and blocking abusive IPs. Limits are tuned based on real traffic data and combined with caching and CDN layers for performance.

Connections

Circuit Breaker Pattern

Both protect systems from overload by controlling request flow.

Understanding rate limiting helps grasp circuit breakers, which stop requests when downstream services fail, improving system resilience.

Traffic Shaping in Networking

Rate limiting is a form of traffic shaping that controls data flow rates.

Knowing how networks shape traffic clarifies how servers manage request rates to avoid congestion.

Queue Management in Operations

Rate limiting manages request queues by controlling arrival rates.

Learning about queue management in operations helps understand how rate limiting prevents system overload by smoothing demand.

Common Pitfalls

#1 Blocking all requests from an IP without exceptions.

Wrong approach:

Rack::Attack.blocklist('block all from IP') do |req|
req.ip == '192.168.1.1'
end

Correct approach:

Rack::Attack.blocklist('block all from IP except trusted users') do |req|
req.ip == '192.168.1.1' && !req.env['warden'].user
end

Root cause:

Not considering trusted users behind shared IPs causes legitimate users to be blocked.

#2 Implementing rate limiting only in controller actions.

Wrong approach:

class ApplicationController < ActionController::Base
before_action :check_rate_limit

def check_rate_limit
if too_many_requests?
render plain: 'Too many requests', status: 429
end
end
end

Correct approach:

class Rack::Attack
throttle('req/ip', limit: 60, period: 1.minute) do |req|
req.ip
end
end

Root cause:

Placing rate limiting in controllers wastes resources and is less effective than middleware.

#3 Using in-memory store for rate limiting in multi-server setup.

Wrong approach:

Rack::Attack.cache.store = ActiveSupport::Cache::MemoryStore.new

Correct approach:

Rack::Attack.cache.store = ActiveSupport::Cache::RedisStore.new('redis://localhost:6379/1')

Root cause:

In-memory stores are local to one server and do not share counts across servers.

Key Takeaways

Rate limiting controls how many requests a server accepts in a time to keep apps stable and fair.

It works best as middleware or with gems like Rack::Attack in Rails, using stores like Redis for tracking.

Good rate limiting balances security and user experience by blocking or throttling requests politely.

Distributed apps need shared storage for accurate limits across servers.

Understanding rate limiting helps protect apps from overload, abuse, and improves reliability.

Practice

1. What is the main purpose of rate limiting in a Rails application?

easy

A. To control how often users can make requests to the server

B. To speed up database queries automatically

C. To style the user interface dynamically

D. To manage user sessions securely

Solution

1. Step 1: Understand rate limiting concept

   Rate limiting is about controlling the number of requests a user can make in a time period.

2. Step 2: Identify the main purpose in Rails context

   It helps protect the server from overload and abuse by limiting request frequency.

3. Final Answer:

   To control how often users can make requests to the server -> Option A

4. Quick Check:

   Rate limiting = controlling request frequency [OK]

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

Common Mistakes:

• Confusing rate limiting with UI styling
• Thinking it speeds up database queries
• Mixing it with session management

2. Which of the following is the correct way to configure a simple rate limit using Rack::Attack in Rails?

easy

A. Rack::Attack.throttle('req/ip', limit: 5, period: 1.minute) { |req| req.ip }

B. Rack::Attack.limit('req/ip', 5, 1.minute) { |req| req.ip }

C. Rack::Attack.throttle('req/ip', 1.minute, limit: 5) { |req| req.ip }

D. Rack::Attack.block('req/ip', limit: 5, period: 1.minute) { |req| req.ip }

Solution

1. Step 1: Recall Rack::Attack throttle syntax

   The correct method is throttle with arguments: name, limit, period, and a block returning the key.

2. Step 2: Match syntax with options

   Rack::Attack.throttle('req/ip', limit: 5, period: 1.minute) { |req| req.ip } uses throttle with named parameters limit: 5 and period: 1.minute, and block returning req.ip, which is correct.

3. Final Answer:

   Rack::Attack.throttle('req/ip', limit: 5, period: 1.minute) { |req| req.ip } -> Option A

4. Quick Check:

   Correct method and parameters = Rack::Attack.throttle('req/ip', limit: 5, period: 1.minute) { |req| req.ip } [OK]

Hint: Use throttle with named limit and period parameters [OK]

Common Mistakes:

• Using wrong method name like limit or block
• Swapping limit and period order
• Not passing a block returning the key

3. Given this Rack::Attack throttle configuration:

Rack::Attack.throttle('logins/ip', limit: 3, period: 20.seconds) { |req| req.ip if req.path == '/login' && req.post? }

What happens if a user makes 4 POST requests to '/login' within 20 seconds from the same IP?

medium

A. Only the 1st request is blocked

B. The 4th request is blocked due to rate limit

C. All 4 requests are allowed without restriction

D. The 4th request resets the limit counter

Solution

1. Step 1: Understand throttle parameters

   The limit is 3 requests per 20 seconds per IP for POST requests to '/login'.

2. Step 2: Analyze 4 POST requests from same IP

   The first 3 requests pass, the 4th exceeds the limit and is blocked.

3. Final Answer:

   The 4th request is blocked due to rate limit -> Option B

4. Quick Check:

   Requests > limit = block excess [OK]

Hint: Requests over limit within period get blocked [OK]

Common Mistakes:

• Assuming all requests pass
• Thinking limit resets on 4th request
• Confusing which requests count

4. You wrote this code to limit API requests:

Rack::Attack.throttle('api/ip', limit: 10, period: 1.minute) do |req|
  req.ip if req.path.start_with?('/api')
end

But users report no limits are applied. What is the likely problem?

medium

A. The period should be in seconds, not minutes

B. The limit value 10 is too high to trigger blocking

C. The block returns nil for non-API paths, so no key is generated for those requests

D. The method throttle is not supported in Rack::Attack

Solution

1. Step 1: Check block return value logic

   The block returns req.ip only if path starts with '/api', else returns nil.

2. Step 2: Understand throttle key generation

   If block returns nil, no key is generated and no limit applies for those requests.

3. Final Answer:

   The block returns nil for non-API paths, so no key is generated for those requests -> Option C

4. Quick Check:

   Nil key means no rate limiting applied [OK]

Hint: Block must return key for all requests to apply limits [OK]

Common Mistakes:

• Thinking limit 10 is too high
• Confusing period units
• Believing throttle method is unsupported

5. You want to limit login attempts per user email and IP address separately using Rack::Attack. Which configuration correctly applies this?

hard

A. Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.params['email'].presence }Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.params['email'] }

B. Rack::Attack.throttle('logins/email_ip', limit: 5, period: 1.hour) { |req| req.params['email'] + req.ip }

C. Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.ip }Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.params['email'] }

D. Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.params['email'] }Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.ip }

Solution

1. Step 1: Understand separate throttles for email and IP

   We want one throttle keyed by email, another keyed by IP address.

2. Step 2: Match keys to correct throttle names

   Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.params['email'] }
   Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.ip } correctly uses req.params['email'] for email throttle and req.ip for IP throttle with proper limits.

3. Final Answer:

   Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.params['email'] }
   Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.ip } -> Option D

4. Quick Check:

   Separate keys for email and IP = Rack::Attack.throttle('logins/email', limit: 5, period: 1.hour) { |req| req.params['email'] }
   Rack::Attack.throttle('logins/ip', limit: 10, period: 1.hour) { |req| req.ip } [OK]

Hint: Use separate throttle blocks keyed by email and IP [OK]

Common Mistakes:

• Mixing email and IP keys in wrong throttles
• Concatenating email and IP as one key
• Using IP where email key is needed