429 Too Many Requests in Rest API - Step-by-Step Execution

Concept Flow - 429 Too Many Requests

Client sends request

↓

Server checks request count

↓

Is request count > limit?

No→Process request

Yes↓

Send 429 Too Many Requests response

↓

Client waits or slows down

↓

Client retries after delay

The server counts client requests and if too many come too fast, it sends a 429 error telling the client to slow down.

Execution Sample

Rest API

GET /api/data
Headers: X-RateLimit-Limit: 5
Headers: X-RateLimit-Remaining: 0
Response: 429 Too Many Requests

Client makes requests; when limit is reached, server responds with 429 error.

Execution Table

Step	Request Number	Request Count	Condition (Count > Limit?)	Action	Response
1	1	1	1 > 5? No	Process request	200 OK
2	2	2	2 > 5? No	Process request	200 OK
3	3	3	3 > 5? No	Process request	200 OK
4	4	4	4 > 5? No	Process request	200 OK
5	5	5	5 > 5? No	Process request	200 OK
6	6	6	6 > 5? Yes	Reject request	429 Too Many Requests

💡 Request count exceeds limit at step 6, server sends 429 error.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	After 6
Request Count	0	1	2	3	4	5	6

Key Moments - 2 Insights

Why does the server send a 429 error at the 6th request?

Because the request count (6) is greater than the allowed limit (5), as shown in execution_table row 6.

What should the client do after receiving a 429 response?

The client should wait or slow down before retrying, as indicated in the concept_flow after the 429 response step.

Visual Quiz - 3 Questions

Look at the execution_table, what is the response at request number 4?

A 500 Internal Server Error

B 429 Too Many Requests

C 200 OK

D 404 Not Found

💡 Hint

Check the Response column at Step 4 in the execution_table.

At which request number does the server start rejecting requests?

A 5

B 6

C 4

D 7

💡 Hint

Look at the Condition and Action columns in the execution_table to find when requests are rejected.

If the limit was increased to 10, what would be the response at request number 6?

A 200 OK

B 429 Too Many Requests

C 404 Not Found

D 500 Internal Server Error

💡 Hint

Refer to the Condition column in execution_table and imagine the limit is 10 instead of 5.

Concept Snapshot

429 Too Many Requests:
- Server limits how many requests a client can make in time.
- If client sends too many, server replies 429 error.
- Client should wait before retrying.
- Helps protect server from overload.

Full Transcript

This visual execution shows how a server handles too many requests from a client. Each request increases the count. When the count exceeds the limit, the server sends a 429 Too Many Requests response. The client must then slow down or wait before sending more requests. This protects the server from overload and keeps the system stable.

Practice

1.

What does the HTTP status code 429 Too Many Requests mean?

easy

A. Your request is missing required authentication credentials.

B. The server could not find the requested resource.

C. You have sent too many requests in a short time and should wait before retrying.

D. The server encountered an unexpected error.

Solution

1. Step 1: Understand HTTP status codes

   HTTP status codes communicate the result of a request. 429 specifically signals rate limiting.

2. Step 2: Interpret 429 meaning

   429 means the client sent too many requests too quickly and must wait before sending more.

3. Final Answer:

   You have sent too many requests in a short time and should wait before retrying. -> Option C

4. Quick Check:

   429 = Too Many Requests [OK]

Hint: 429 means slow down your requests and try again later [OK]

Common Mistakes:

• Confusing 429 with 404 Not Found
• Thinking 429 means authentication error
• Ignoring the need to wait before retrying

2.

Which HTTP header is commonly used by servers to tell clients how long to wait before retrying after a 429 Too Many Requests response?

easy

A. Content-Type

B. Retry-After

C. Authorization

D. User-Agent

Solution

1. Step 1: Identify headers related to retrying

   When a server limits requests, it often tells clients how long to wait using a specific header.

2. Step 2: Match header to purpose

   The Retry-After header indicates the wait time before retrying after 429.

3. Final Answer:

   Retry-After -> Option B

4. Quick Check:

   Retry-After header = wait time [OK]

Hint: Retry-After tells you when to try again after 429 [OK]

Common Mistakes:

• Choosing Content-Type which describes data format
• Confusing Authorization with retry timing
• Selecting User-Agent which identifies client software

3.

Consider this server response to a client request:

{
  "status": 429,
  "headers": {"Retry-After": "10"},
  "body": "Too many requests, please wait."
}

If the client immediately retries the request after 5 seconds, what is the likely result?

medium

A. The server will respond with another 429 status, indicating to wait longer.

B. The server will accept the request and respond normally.

C. The server will respond with a 404 Not Found error.

D. The server will close the connection without response.

Solution

1. Step 1: Analyze Retry-After header value

   The server asks the client to wait 10 seconds before retrying.

2. Step 2: Evaluate client retry timing

   The client retries after only 5 seconds, which is less than 10 seconds.

3. Step 3: Predict server response

   The server will reject the early retry and respond with 429 again.

4. Final Answer:

   The server will respond with another 429 status, indicating to wait longer. -> Option A

5. Quick Check:

   Retry before 10s = 429 again [OK]

Hint: Retry only after Retry-After seconds to avoid repeated 429 [OK]

Common Mistakes:

• Assuming server accepts early retries
• Confusing 429 with 404 errors
• Thinking server silently drops requests

4.

Given this snippet of server-side pseudocode handling API requests:

if request_count > limit:
    return 429, {"Retry-After": "30"}, "Too many requests"
else:
    process_request()

What is a likely bug if clients keep getting 429 responses even after waiting 30 seconds?

medium

A. The server is processing requests without any limit.

B. The Retry-After header is missing from the response.

C. The server is not checking request_count at all.

D. The server does not reset request_count after the wait period.

Solution

1. Step 1: Understand rate limiting logic

   The server limits requests by counting them and returning 429 if over limit.

2. Step 2: Identify why 429 repeats after wait

   If request_count never resets, the server always thinks limit is exceeded.

3. Step 3: Confirm bug cause

   Not resetting request_count after wait causes repeated 429 responses.

4. Final Answer:

   The server does not reset request_count after the wait period. -> Option D

5. Quick Check:

   Persistent 429 means counter not reset [OK]

Hint: Reset request count after wait to avoid repeated 429 [OK]

Common Mistakes:

• Ignoring the need to reset counters
• Assuming Retry-After header alone fixes issue
• Thinking server ignores request limits

5.

You are designing a client application that calls a public API which may respond with 429 Too Many Requests. How should your client handle this to avoid errors and respect the server?

hard

A. Read the Retry-After header and wait that many seconds before retrying.

B. Stop all requests permanently after the first 429 response.

C. Ignore the 429 response and retry immediately until successful.

D. Send multiple requests in parallel to speed up retries.

Solution

1. Step 1: Understand respectful client behavior

   Clients should avoid overwhelming servers by respecting rate limits.

2. Step 2: Use Retry-After header properly

   The server provides Retry-After to tell clients how long to wait before retrying.

3. Step 3: Implement waiting before retry

   Client should pause for the specified time, then retry to avoid repeated 429 errors.

4. Final Answer:

   Read the Retry-After header and wait that many seconds before retrying. -> Option A

5. Quick Check:

   Respect Retry-After to avoid 429 [OK]

Hint: Always wait Retry-After seconds before retrying after 429 [OK]

Common Mistakes:

• Retrying immediately ignoring Retry-After
• Stopping requests forever after one 429
• Sending many parallel requests causing more 429s