Per-user vs per-IP limits in Rest API - Trade-offs & Expert Analysis

Overview - Per-user vs per-IP limits

What is it?

Per-user and per-IP limits are ways to control how many requests a client can make to a server in a given time. Per-user limits track usage based on a user's identity, while per-IP limits track usage based on the client's internet address. These limits help keep the server stable and fair for everyone by preventing too many requests from one source.

Why it matters

Without these limits, a few users or devices could overload the server, causing slowdowns or crashes for everyone else. They also help stop abuse like spamming or hacking attempts. Using limits ensures a smooth experience and protects resources, making the service reliable and fair.

Where it fits

Before learning this, you should understand basic REST API concepts and how clients communicate with servers. After this, you can explore advanced rate limiting techniques, authentication methods, and security best practices.

Mental Model

Core Idea

Rate limits control how often a client can ask a server for data, either by tracking who they are or where they come from.

Think of it like...

It's like a library that lets each person borrow only a few books at a time (per-user), or limits how many books can be borrowed from one neighborhood (per-IP) to keep things fair.

┌───────────────┐       ┌───────────────┐
│   Client A    │       │   Client B    │
│ (User ID 123) │       │ (User ID 456) │
└──────┬────────┘       └──────┬────────┘
       │                       │
       ▼                       ▼
┌─────────────────────────────────────┐
│          Server with Limits          │
│ ┌───────────────┐  ┌───────────────┐│
│ │Per-user limit  │  │Per-IP limit   ││
│ │(User ID 123)  │  │(IP 192.0.2.1) ││
│ └───────────────┘  └───────────────┘│
└─────────────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is Rate Limiting

Concept: Introduce the basic idea of limiting how often clients can make requests.

Rate limiting means setting a maximum number of requests a client can send to a server in a certain time, like 100 requests per minute. This prevents overload and abuse.

Result

Clients cannot send unlimited requests; the server controls traffic to stay stable.

Understanding rate limiting is key to protecting servers from being overwhelmed by too many requests.

2

Foundation

Identifying Clients: User vs IP

Concept: Explain the two main ways to identify who is making requests: by user identity or by IP address.

Per-user limits track requests based on a user ID, like a login name. Per-IP limits track requests based on the client's IP address, which is like their internet location.

Result

You know there are two main ways to count requests: by who the user is or where the request comes from.

Knowing how clients are identified helps decide which limit type to use for different situations.

3

Intermediate

How Per-user Limits Work

🤔Before reading on: do you think per-user limits work if users share devices? Commit to your answer.

Concept: Per-user limits count requests by user identity, regardless of device or IP.

When a user logs in, the server tracks how many requests that user makes. If the user exceeds the limit, the server blocks further requests until the time resets.

Result

Users cannot exceed their allowed request count, even if they switch devices or IPs.

Understanding per-user limits helps protect individual accounts from abuse, even if attackers change IPs.

4

Intermediate

How Per-IP Limits Work

🤔Before reading on: do you think per-IP limits can block multiple users behind one network? Commit to your answer.

Concept: Per-IP limits count requests based on the client's IP address, regardless of user identity.

The server tracks how many requests come from each IP address. If the IP exceeds the limit, all requests from that IP are blocked temporarily.

Result

Clients sharing the same IP share the request limit, which can block multiple users at once.

Knowing per-IP limits helps understand how networks with shared IPs can be affected by rate limiting.

5

Intermediate

Comparing Per-user and Per-IP Limits

🤔Before reading on: which limit do you think is better for public APIs without login? Commit to your answer.

Concept: Explore strengths and weaknesses of each limit type and when to use them.

Per-user limits work well when users log in, protecting accounts individually. Per-IP limits work for anonymous users but can block many people behind one IP, like offices or schools.

Result

You can choose the right limit type based on your API's user setup and goals.

Understanding trade-offs helps design fair and effective rate limiting strategies.

6

Advanced

Combining Per-user and Per-IP Limits

🤔Before reading on: do you think combining limits can cause more false blocks or fewer? Commit to your answer.

Concept: Using both limits together to balance protection and fairness.

Many systems apply per-user limits for logged-in users and per-IP limits for anonymous users. This layered approach reduces abuse while minimizing accidental blocks.

Result

The server better handles different client types and reduces risks of overload or unfair blocking.

Knowing how to combine limits improves real-world API reliability and user experience.

7

Expert

Handling Edge Cases and Bypass Risks

🤔Before reading on: can attackers bypass per-IP limits by changing IPs? Commit to your answer.

Concept: Explore how attackers might evade limits and how to defend against it.

Attackers can use many IPs (botnets) to bypass per-IP limits or create many accounts to bypass per-user limits. Defenses include CAPTCHA, behavioral analysis, and adaptive limits.

Result

You understand the limits of rate limiting and the need for layered security.

Recognizing bypass methods helps build stronger, more resilient APIs.

Under the Hood

Rate limiting works by storing counters for each user ID or IP address in fast storage like memory or a cache. Each request increments the counter. When the count exceeds the limit within the time window, the server rejects requests. The counters reset after the window expires. Efficient data structures and algorithms ensure minimal delay and memory use.

Why designed this way?

This design balances performance and fairness. Tracking by user ID allows precise control for authenticated users, while IP tracking covers anonymous clients. Alternatives like global limits are too coarse, and per-device limits are hard to enforce. The time window approach smooths bursts and prevents sudden overloads.

┌───────────────┐
│ Incoming Req  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Identify User │
│ or IP Addr    │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Check Counter │
│ for User/IP   │
└──────┬────────┘
       │
   ┌───┴─────┐
   │         │
   ▼         ▼
┌────────┐ ┌─────────────┐
│ Below  │ │ Exceeded    │
│ Limit  │ │ Limit       │
└──┬─────┘ └────┬────────┘
   │            │
   ▼            ▼
┌────────┐ ┌─────────────┐
│ Allow  │ │ Reject with │
│ Request│ │ Error       │
└────────┘ └─────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does per-IP limiting always protect individual users fairly? Commit yes or no.

Common Belief: Per-IP limits protect each user fairly because they block bad clients by IP.

Reality: Per-IP limits can unfairly block many users sharing the same IP, like in offices or public Wi-Fi.

Why it matters: This can cause good users to lose access, harming user experience and trust.

Quick: Can per-user limits stop attackers who create many accounts? Commit yes or no.

Common Belief: Per-user limits stop abuse because each user has a strict request cap.

Reality: Attackers can create many fake accounts to bypass per-user limits, making them less effective alone.

Why it matters: Relying only on per-user limits can leave APIs vulnerable to mass account abuse.

Quick: Is it safe to rely on IP addresses for client identity? Commit yes or no.

Common Belief: IP addresses uniquely identify clients, so they are reliable for limits.

Reality: IP addresses can be shared, dynamic, or masked by proxies, making them unreliable identifiers.

Why it matters: Misusing IPs can cause incorrect blocking or let attackers slip through.

Quick: Does combining per-user and per-IP limits always reduce false blocks? Commit yes or no.

Common Belief: Combining both limits always improves fairness and security.

Reality: Combining limits can increase complexity and sometimes cause more false positives if not tuned well.

Why it matters: Poorly configured combined limits can frustrate users and increase support costs.

Expert Zone

1

Per-user limits require reliable user authentication; weak auth can undermine their effectiveness.

2

Per-IP limits must consider IPv6 and NAT scenarios where many users share one IP or one user has many IPs.

3

Adaptive rate limiting that changes limits based on behavior or risk scores improves security without hurting good users.

When NOT to use

Avoid per-user limits for public APIs without authentication; use per-IP or token-based limits instead. Avoid per-IP limits in environments with many users behind shared IPs, like corporate networks. Consider token bucket or leaky bucket algorithms for smoother rate limiting instead of fixed windows.

Production Patterns

Real-world APIs often combine per-user limits for authenticated endpoints with per-IP limits for anonymous access. They use distributed caches like Redis to store counters and apply exponential backoff or CAPTCHA challenges when limits are hit. Monitoring and alerting on rate limit events help detect attacks early.

Connections

Authentication and Authorization

Per-user limits depend on knowing who the user is, which requires authentication.

Understanding authentication helps grasp how per-user limits can be enforced accurately and securely.

Network Address Translation (NAT)

NAT causes many users to share one IP, affecting per-IP limit fairness.

Knowing NAT explains why per-IP limits can block multiple users unintentionally.

Traffic Shaping in Networking

Rate limiting is similar to traffic shaping, controlling flow to prevent congestion.

Seeing rate limits as traffic control helps understand their role in maintaining system stability.

Common Pitfalls

#1 Blocking users too aggressively by IP without considering shared networks.

Wrong approach:

if (requests_from_ip > limit) { block_all_requests(); }

Correct approach:

if (requests_from_ip > limit && suspicious_behavior_detected) { block_requests(); }

Root cause:

Assuming each IP corresponds to one user, ignoring shared IP scenarios.

#2 Applying per-user limits without verifying user identity properly.

Wrong approach:

count_requests(user_id_from_untrusted_header);

Correct approach:

count_requests(user_id_from_secure_auth_token);

Root cause:

Trusting client-supplied data without secure authentication.

#3 Resetting rate limit counters too frequently, allowing bursts.

Wrong approach:

reset_counters_every_second();

Correct approach:

use_sliding_window_or_token_bucket_algorithm();

Root cause:

Using fixed windows without smoothing causes uneven request bursts.

Key Takeaways

Per-user and per-IP limits are essential tools to control how often clients can access APIs, protecting servers from overload and abuse.

Per-user limits rely on knowing who the user is, making them effective for authenticated services but vulnerable to fake accounts.

Per-IP limits track requests by internet address, useful for anonymous users but can unfairly affect many users behind shared IPs.

Combining both limit types and using adaptive strategies improves fairness and security but requires careful tuning.

Understanding the network environment, authentication methods, and attacker tactics is crucial to designing effective rate limiting.

Practice

1. What is the main difference between per-user and per-IP rate limits in REST APIs?

easy

A. Per-user limits block IP addresses; per-IP limits block user accounts.

B. Per-user limits count requests from each IP; per-IP limits count requests from each user.

C. Per-user limits track requests by user identity; per-IP limits track requests by the requester's IP address.

D. Per-user limits apply only to logged-out users; per-IP limits apply only to logged-in users.

Solution

1. Step 1: Understand per-user limits

   Per-user limits count how many requests each user (identified by login or token) makes.

2. Step 2: Understand per-IP limits

   Per-IP limits count requests based on the IP address making the request, regardless of user identity.

3. Final Answer:

   Per-user limits track requests by user identity; per-IP limits track requests by the requester's IP address. -> Option C

4. Quick Check:

   Per-user = user identity, Per-IP = IP address [OK]

Hint: User limits track users; IP limits track locations [OK]

Common Mistakes:

• Confusing user identity with IP address
• Thinking per-IP limits block users
• Assuming per-user limits apply only to logged-out users

2. Which of the following is the correct way to check a per-user rate limit in pseudocode?

easy

A. if requests_from_user > limit: block_request()

B. if requests_from_ip > limit: block_request()

C. if user_ip == limit: block_request()

D. if user == limit: block_request()

Solution

1. Step 1: Identify per-user check

   Per-user limits check how many requests a user has made, so the condition should compare requests_from_user to the limit.

2. Step 2: Verify correct syntax

   The correct syntax is to compare requests_from_user > limit and block if true.

3. Final Answer:

   if requests_from_user > limit: block_request() -> Option A

4. Quick Check:

   Check user requests count > limit [OK]

Hint: Per-user means check requests_from_user variable [OK]

Common Mistakes:

• Using IP variable for per-user limit
• Comparing user or IP directly to limit
• Using equality instead of greater than

3. Given this pseudocode snippet for rate limiting:

requests_per_user = {"alice": 5, "bob": 3}
requests_per_ip = {"192.168.1.1": 10, "10.0.0.2": 2}
user = "alice"
ip = "192.168.1.1"
user_limit = 5
ip_limit = 10

if requests_per_user[user] >= user_limit:
    print("User limit reached")
elif requests_per_ip[ip] >= ip_limit:
    print("IP limit reached")
else:
    print("Request allowed")

What will be printed?

medium

A. Request allowed

B. User limit reached

C. IP limit reached

D. Error: Key not found

Solution

1. Step 1: Check user request count

   requests_per_user["alice"] is 5, which is equal to user_limit (5), so the first if condition is true.

2. Step 2: Determine which print runs

   Since the first condition is true, it prints "User limit reached" and skips the rest.

3. Final Answer:

   User limit reached -> Option B

4. Quick Check:

   5 >= 5 triggers user limit [OK]

Hint: Check user count first; equal means limit reached [OK]

Common Mistakes:

• Thinking IP limit triggers first
• Ignoring >= condition
• Assuming else runs when equal

4. This code snippet is intended to enforce per-IP rate limits but has a bug:

requests_per_ip = {"1.2.3.4": 8}
ip_limit = 10
ip = "1.2.3.4"

if requests_per_ip[ip] > ip_limit:
    print("Limit exceeded")
else:
    print("Allowed")

What is the bug and how to fix it?

medium

A. Bug: Uses > instead of >=; fix by changing to >=.

B. Bug: ip variable is wrong type; fix by converting to string.

C. Bug: requests_per_ip key missing; fix by adding default value.

D. Bug: prints wrong message; fix by swapping print statements.

Solution

1. Step 1: Analyze condition logic

   The code blocks requests only if requests_per_ip[ip] > ip_limit, so if requests equal ip_limit, it allows the request.

2. Step 2: Fix condition to include equal case

   Change > to >= so requests equal to ip_limit also get blocked.

3. Final Answer:

   Bug: Uses > instead of >=; fix by changing to >=. -> Option A

4. Quick Check:

   Use >= to block at limit [OK]

Hint: Use >= to block requests at limit, not just above [OK]

Common Mistakes:

• Ignoring equal case in condition
• Assuming IP variable type is wrong
• Thinking missing keys cause this bug

5. You want to implement a rate limiter that blocks requests if either the user or the IP address exceeds their limits. Which pseudocode correctly enforces this combined rule?

hard

A. if requests_per_user[user] > user_limit and requests_per_ip[ip] > ip_limit:
block_request()

B. if requests_per_user[user] == user_limit and requests_per_ip[ip] == ip_limit:
block_request()

C. if requests_per_user[user] < user_limit or requests_per_ip[ip] < ip_limit:
block_request()

D. if requests_per_user[user] > user_limit or requests_per_ip[ip] > ip_limit:
block_request()

Solution

1. Step 1: Understand combined blocking logic

   The request should be blocked if either the user or the IP exceeds their limit, so the condition must use OR.

2. Step 2: Check condition correctness

   if requests_per_user[user] > user_limit or requests_per_ip[ip] > ip_limit: block_request() uses OR with > comparisons, correctly blocking if user or IP exceeds limits.

3. Final Answer:

   if requests_per_user[user] > user_limit or requests_per_ip[ip] > ip_limit: block_request() -> Option D

4. Quick Check:

   Block if user OR IP exceeds limit [OK]

Hint: Use OR to block if either user or IP exceeds limit [OK]

Common Mistakes:

• Using AND instead of OR
• Using < instead of >
• Checking equality only