github.com/hellofresh/janus@v0.0.0-20230925145208-ce8de8183c67/docs/plugins/rate_limit.md (about) 1 # Rate Limiting 2 3 Rate limit how many HTTP requests a developer can make in a given period of seconds, minutes, hours, days, months or years. 4 5 ## Configuration 6 7 The plain rate limit config: 8 9 ```json 10 "rate_limit": { 11 "enabled": true, 12 "config": { 13 "limit": "10-S", 14 "policy": "local", 15 "trust_forward_headers": false 16 } 17 } 18 ``` 19 20 | Configuration | Description | 21 |----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 22 | limit | Defines the limit rule for the proxy. i.e. 5 reqs/second: `5-S`, 10 reqs/minute: `10-M`, 1000 reqs/hour: `1000-H` | 23 | policy | The rate-limiting policies to use for retrieving and incrementing the limits. Available values are `local` (counters will be stored locally in-memory on the node) and `redis` (counters are stored on a Redis server and will be shared across the nodes). | 24 | redis.dsn | The DSN for the redis instance/cluster to be used | 25 | redis.prefix | A prefix to be used on redis keys. It defaults to `limiter` | | 26 | trust_forward_headers | If set to True, `X-Forwarded-For` and `X-Real-IP` headers will be used instead of the source ip. Defaults to False. | 27 28 ## Headers sent to the client 29 30 When this plugin is enabled, Janus will send some additional headers back to the client telling how many requests are available and what are the limits allowed, for example: 31 32 ``` 33 X-Ratelimit-Limit: 10 34 X-Ratelimit-Remaining: 9 35 X-Ratelimit-Reset: 1491383478 36 ``` 37 38 If any of the limits configured is being reached, the plugin will return a HTTP/1.1 `429` status code to the client with the following plain text body: 39 40 ``` 41 Limit exceeded 42 ``` 43 44 # Implementation considerations 45 46 The plugin supports 3 policies, which each have their specific pros and cons. 47 48 | Policy | Pros | Cons | 49 |--------|-----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------| 50 | redis | accurate, lesser performance impact than a cluster policy | extra redis installation required, bigger performance impact than a local policy | 51 | local | minimal performance impact | less accurate, and unless a consistent-hashing load balancer is used in front of Janus, it diverges when scaling the number of nodes | 52 53 There are 2 use cases that are most common: 54 55 ### 1. every transaction counts. 56 These are for example transactions with financial consequences. Here the highest level of accuracy is required. 57 58 ### 2. backend protection. 59 This is where accuracy is not as relevant, but it is merely used to protect backend services from overload. Either by specific users, or to protect against an attack in general. 60 61 > NOTE: the redis policy does not support the Sentinel protocol for high available master-slave architectures. When using rate-limiting for general protection the chances of both redis being down and the system being under attack are rather small. Check with your own use case wether you can handle this (small) risk.