Versions Compared
Version | Old Version 9 | New Version 10 |
---|---|---|
Changes made by | ||
Saved on |
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Tip |
---|
The Framework proposed in this space (Alex Xu) is applied to propose a design : Getting started - a framework to propose... |
Introduction
The benefits of using an API rate limiter :
Prevent resource starvation caused by Denial of Service (DoS) attack, either intentional or unintentional, by blocking the excess calls.
Reduce cost by limiting servers and allocating more resources to high priority APIs. Important when we use paid third party APIs.
Prevent servers from being overloaded by filtering out excess requests.
on this page.
Table of Contents |
---|
Part 1 - Understand the problem and establish design scope
Type of rate limiter ? client-side or server-side ? Or in a middleware ? | Server-Side or Middleware |
---|---|
Rules of throttle ? | Different sets of throttle rules (IP, user ID, etc.) |
Scale of the system ? Small, Medium, big company | Big company |
In a distributed environment ? | Yes. |
Implemented as a separate service or in application code ? | No matter. |
Inform user who are throttled? | Yes. |
Additional requirements to consider
limit excessive requests
low latency - not slow down http response time
limit the use of memory as possible
can be shared across servers and processes
exception handling - show clear exceptions to users
high fault tolerance - if rate limiter goes offline, it does not affect the system
Part 2 - High level design
Client-side implementation is not the right option because client is not a reliable place : client requests can be forged by malicious actors.

API Gateway is a fully managed service supporting rate limiting, SSL termination, authentication, IP whitelisting, etc.