Per-user vs per-IP limits in Rest API - Visual Side-by-Side Comparison

Concept Flow - Per-user vs per-IP limits

Request Received

↓

Identify User or IP

↓

Check Limit Type

↓

Per-User

↓

Limit Exceeded?

No→Allow Request

↓

Reject Request

When a request comes in, the system identifies if limits apply per user or per IP, checks the count, and either allows or rejects the request.

Execution Sample

Rest API

def check_limit(request):
    id = request.user_id or request.ip
    limit = 5 if request.user_id else 3
    count = get_request_count(id)
    if count >= limit:
        return 'Limit Exceeded'
    else:
        increment_count(id)
        return 'Allowed'

This code checks if a request exceeds the limit based on user ID or IP address and returns if it's allowed or rejected.

Execution Table

Step	Request ID (User/IP)	Current Count	Condition (count >= LIMIT)	Action	Result
1	User123	4	4 >= 5? False	increment_count(User123)	Allowed
2	User123	5	5 >= 5? True	reject request	Limit Exceeded
3	192.168.1.1	2	2 >= 3? False	increment_count(192.168.1.1)	Allowed
4	192.168.1.1	3	3 >= 3? True	reject request	Limit Exceeded
5	User456	0	0 >= 5? False	increment_count(User456)	Allowed
6	User456	1	1 >= 5? False	increment_count(User456)	Allowed
7	User456	5	5 >= 5? True	reject request	Limit Exceeded

💡 Requests are rejected once the count reaches or exceeds the limit.

Variable Tracker

ID	Start	After 1	After 2	After 3	After 4	After 5	After 6	Final
User123	4	5	5	5	5	5	5	5
192.168.1.1	2	3	3	3	3	3	3	3
User456	0	1	2	3	4	5	5	5

Key Moments - 3 Insights

Why does the request get rejected when count equals the limit, not just when it exceeds?

Because the condition uses '>=' (greater or equal), so reaching the limit count triggers rejection as shown in rows 2, 4, and 7 of the execution_table.

How does the system decide whether to use user ID or IP for counting?

It first tries to identify the user ID; if not available, it falls back to the IP address, as shown in the code sample where 'id = request.user_id or request.ip'.

Can different users from the same IP share the same limit?

If limits are per-IP, yes; all requests from that IP share the count. If per-user, each user has their own count. This distinction is shown in the concept_flow branching.

Visual Quiz - 3 Questions

Look at the execution_table, what is the count for User123 at step 2?

A 4

B 5

C 6

D 3

💡 Hint

Check the 'Current Count' column at step 2 in the execution_table.

At which step does the IP 192.168.1.1 reach its limit?

A Step 5

B Step 3

C Step 4

D Step 2

💡 Hint

Look for when 'Condition (count >= LIMIT)' becomes True for 192.168.1.1 in the execution_table.

If the limit for users was increased to 6, what would happen at step 7 for User456?

A Request would be allowed

B Request would be rejected

C Count would reset

D No change

💡 Hint

Refer to the condition check in the execution_table and consider how changing LIMIT affects it.

Concept Snapshot

Per-user vs per-IP limits control how many requests are allowed.
Identify user ID first; if missing, use IP address.
Check request count against a limit.
If count >= limit, reject request.
Otherwise, increment count and allow.
This prevents abuse by users or IPs.

Full Transcript

When a request arrives, the system first identifies if it can track the user by user ID. If no user ID is found, it uses the IP address instead. Then it checks how many requests have been made by that user or IP. If the count is equal to or greater than the allowed limit, the request is rejected. Otherwise, the count is increased by one and the request is allowed. This approach helps control traffic and prevent abuse either per individual user or per IP address. The execution table shows examples of counts increasing and when requests get rejected once limits are reached.