Request flows

why use API Gateway instead of Load Balancer

need an application-level component that can run that logic per request. A simple load balancer can’t interpret your rate-limit rules, hit Redis, or return a custom 429 payload—it can only proxy TCP/HTTP.

Flow Steps:

When a client sends a request to a server, the request is sent to API Gateway first.
Rate limiting rules are stored in disk (API-Gateway host’s local filesystem )as config files. Workers frequently pulls the rate limiting rules from disk and load it to rule cache (In-Memory Map/Hash on API Gateway).
1. This “pull-and-cache” pattern lets you manage and update your rate-limit rules dynamically without touching or restarting the API Gateway itself
API gateway get the counter from the memory (redis) and the rule from the rule cache. it decides if the request is passed or throttled.
1. If the request is passed, it is redirected to the API servers.
2. If the request is throttled, it returns a response to the client with the response code 429 (too many requests). In some cases, the request can be pushed to a queue for later processing.

Rate Limiting Rule:

The rate limiting rules can be stored in disk as config files. For example:

{

"rules": [

"rate_limit": {

"unit": "minute",

"requests_per_unit": 5,

"burst_capacity": 10 # for token-bucket bursts

},

"algorithm": "token_bucket", # or fixed_window, sliding_window_log, etc.

}

]

}

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10