https://github.com/ikeasamoahansah/rate-x

A simple rate limiter
https://github.com/ikeasamoahansah/rate-x

Last synced: about 1 month ago
JSON representation

A simple rate limiter

• Host: GitHub
• URL: https://github.com/ikeasamoahansah/rate-x
• Owner: ikeasamoahansah
• License: mit
• Created: 2024-12-02T23:16:16.000Z (about 2 months ago)
• Default Branch: main
• Last Pushed: 2024-12-02T23:28:54.000Z (about 2 months ago)
• Last Synced: 2024-12-03T00:26:17.971Z (about 2 months ago)
• Size: 1.95 KB
• Stars: 0
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
# rate-x

A simple rate limiter

## TODO:

- Functional Requirements:

    - limit calls to API

    - eg. 2 requests/second

    - how to display to user

- Non functional Requirements:

    - what kind (client side, server, middleware)

    - is high availability required?

    - pitfalls? performance?

    - should be fast and use little memory

    - should placed in between client and server

- Data Modelling:

    - which database

    - mysql (relational) not optimal, too slow.

    - redis is better

### Algorithms

- Leaking Bucket:

    - can start by implementing this algo

    - it uses a queue based system FIFO

    - parameters(bucket_size, process_rate)

    - memory efficient, stable processing -> advantages

    - weak support for burst traffic, parameters difficult to get right -> disadv

- Token Bucket:

    - similar to leaking bucket but uses token

    - dynamic rate of processing

    - predefined capacity

    - parameters(bucket_size, refill_rate)

    - buckets needed depends on our needs

    - bets to have diff buckets for every endpoint

    - tiny memory usage, allows burst of traffic -> pros

    - parameters difficult to adjust -> cons

- Fixed Window:

    - divides timeline into fixed sized windows

    - easy to implement, small memory -> pros

    - not accurate because more requests can go through -> cons

- Sliding Window:

    - assumes a constant rate of requests

    - good enough accuracy, memory eff, no starvation problem -> pros

    - not exactly accurate -> cons