Πώς σχεδιάζετε rate limiting;

Question

Accepted Answer

**Rate limiting** περιορίζει πόσα αιτήματα μπορεί να κάνει ένας client σε ένα χρονικό παράθυρο — προστατεύοντας τα συστήματα από κακόχρηση, υπερφόρτωση και διασφαλίζοντας δίκαιη χρήση. Είναι ένα κοινό συστατικό σχεδιασμού συστημάτων, με αρκετούς αλγόριθμους και θέσεις προς εξέταση.

## Γιατί είναι σημαντικό το rate limiting

```text
✓ PROTECT against abuse → prevent attacks (brute force, scraping, DoS), excessive use
✓ PREVENT OVERLOAD → protect the system from being overwhelmed (stability)
✓ FAIR USAGE → ensure no single client monopolizes resources; tiered limits (free vs paid)
✓ COST control; protect downstream services
→ a common requirement for APIs and services.
```

## Αλγόριθμοι rate limiting

```text
FIXED WINDOW → count requests per fixed time window (e.g. 100/minute); simple
  ✗ allows bursts at window boundaries (up to 2x at the edges)
SLIDING WINDOW → rolling time window → smoother, no boundary bursts (more accurate)
TOKEN BUCKET → tokens refill at a rate; each request takes a token → allows BURSTS up to
  the bucket size while limiting the average rate (popular, flexible)
LEAKY BUCKET → requests processed at a steady rate (smooths output)
```

## Θέσεις υλοποίησης

```text
✓ DISTRIBUTED → limits must be shared across servers → use a centralized store (REDIS is
  common: atomic counters, fast, shared across instances)
✓ Identify the client → by API key, user ID, IP
✓ Return clear responses → HTTP 429 (Too Many Requests); include limit/retry-after headers
✓ Where → at the API gateway, load balancer, or application layer
✓ Granularity → per user, per endpoint, global; different tiers/limits
```

## Γιατί έχει σημασία

Η κατανόηση του σχεδιασμού του rate limiting είναι πολύτιμη επειδή είναι ένα **κοινό συστατικό σχεδιασμού συστημάτων** για την προστασία των συστημάτων και τη διασφάλιση δίκαιης χρήσης, οπότε είναι σημαντική πρακτική γνώση.

Το rate limiting — ο περιορισμός του πόσα αιτήματα μπορεί να κάνει ένας client σε ένα χρονικό παράθυρο — αντιμετωπίζει σημαντικές ανάγκες: **προστασία από κακόχρηση** (αποτροπή επιθέσεων όπως brute force, scraping και DoS), **αποτροπή υπερφόρτωσης** (προστασία της σταθερότητας του συστήματος), διασφάλιση **δίκαιης χρήσης** (κανένας client δεν μονοπωλεί πόρους, υποστήριξη διαβαθμισμένων ορίων όπως δωρεάν έναντι επί πληρωμή), και έλεγχος κόστους.

Αυτά κάνουν το rate limiting ένα κοινό απαίτημα για APIs και υπηρεσίες.

Η κατανόηση των **αλγορίθμων** και των αντικλήσεών τους — **fixed window** (απλό αλλά επιτρέποντας ξεσπάσματα στα όρια), **sliding window** (πιο ομαλό και ακριβέστερο), **token bucket** (επιτρέποντας ελεγχόμενα ξεσπάσματα ενώ περιορίζει το μέσο ρυθμό — δημοφιλές και ευέλικτο), και leaky bucket (ομαλοποίηση εξόδου) — είναι η βασική γνώση σχεδιασμού, επειδή η επιλογή του σωστού αλγορίθμου επηρεάζει τη συμπεριφορά.

Η κατανόηση των **θέσεων υλοποίησης** είναι ιδιαίτερα σημαντική: διαχείριση **διανεμημένου rate limiting** (όρια κοινά σε πολλούς διακομιστές, συνήθως χρησιμοποιώντας **Redis** για γρήγορα ατομικά counters κοινά μεταξύ στιγμιοτύπων — επειδή τα όρια ανά διακομιστή δεν λειτουργούν σε διανεμημένα συστήματα), αναγνώριση clients (με API key, χρήστη ή IP), επιστροφή σαφών απαντήσεων (HTTP 429 με retry-after headers), επιλογή όπου να το εφαρμόσετε (gateway, load balancer ή εφαρμογή), και κοκκιμότητα (ανά χρήστη, ανά endpoint, διαβαθμισμένα).

Αυτά αντικατοπτρίζουν το σχεδιασμό του rate limiting που λειτουργεί σε πραγματικά διανεμημένα συστήματα.

Το rate limiting είναι ένα συστατικό που χρειάζεται συχνά, που εμφανίζεται συχνά σε συζητήσεις και συνεντεύξεις σχεδιασμού συστημάτων.

Επειδή το rate limiting είναι ένα κοινό, σημαντικό συστατικό για την προστασία των συστημάτων (από κακόχρηση και υπερφόρτωση) και τη διασφάλιση δίκαιης χρήσης, και επειδή η κατανόηση των αλγορίθμων, των αντικλήσεών τους και ειδικά της διανεμημένης υλοποίησης (κοινά όρια μέσω Redis) είναι σημαντική για το σχεδιασμό του καλά, η κατανόηση του σχεδιασμού του rate limiting είναι πολύτιμη, πρακτικά σχετική γνώση σχεδιασμού συστημάτων — ένα κοινό συστατικό για την προστασία των υπηρεσιών και τη διασφάλιση δίκαιης χρήσης, απαιτώντας κατανόηση των αλγορίθμων και της διανεμημένης υλοποίησης, και ένα συχνά συζητημένο θέμα στο σχεδιασμό συστημάτων για την κατασκευή ισχυρών, προστατευμένων συστημάτων.