# RelaxedRateLimiter

This is a high-throughput, approximate rate limiter for BEAM, started as a [Hammer fork](https://hexdocs.pm/hammer/readme.html)
It prioritizes speed over global correctness.
If you need exact limits, do not use this.

## Installation

RelaxedRateLimiter is available on hex.pm.

To add it to a mix project, just add a line like this in your deps function in mix.exs:

```
defp deps do
  [
    {:relaxed_rate_limiter, "~> 1.4", only: [:dev, :test], runtime: false},
  ]
end
```


## Configuration


## Comparation

I honestly suggest you to use hammer if you're not sure what to use. It's battle-tested, developed by incredible good engineers project which will fit most cases better than this project

| takes |   | [hammer](https://hexdocs.pm/hammer/readme.html) | [ex_rated](https://github.com/grempe/ex_rated) | **relaxed_rate_limiter** |
| ----- | - | ------------------------- | ------------------------ | ------------------------------ |
| read  |   | fast (ets lookup)         | fast (ets lookup)        | fast (ets lookup)              |
| write |   | medium (update+broadcast) | fast (update+no sync)    | fast (update)                  |
| sync  |   | per insert broadcast      | nothing (do it yourself) | total nodes count              |
| count |   | strict                    | strict                   | approximated, with high drifts |

## Functionality

**relaxed_rate_limiter** will keep our API rate limiting simple (no broadcast overhead), still supporting distributed setup. It should not be used to track API or plan usage! It tolerate values a lot and accept approximation in the rate limiting (**it's only purpose it to keep Nodes alive**)

1. Leaked bucket algorithm
   - Fills up with requests at the input rate
   - "Leaks" requests at a constant rate
   - Has a maximum capacity (the bucket size)
2. Out Of Memory guard _OOM are the most dangerous errors_ 
   - Each period check Node/Machine memory usage
   - Turn global "Too many requests" until will be back to "fine" state