Studiu de caz / 03

Rate Limit - Comparație de Algoritmi Implementați de la Zero

O soluție de limitare a ratei de cereri pregătită pentru producție, care implementează algoritmii Fixed Window Counter și Sliding Window Log de la zero, cu backend-uri de stocare interschimbabile, configurare per client și teste care demonstrează exact unde dă greș fixed window.

Statut: Proiect selectat
Contextul sistemului: TypeScript, Node.js, Express.js, Redis
Sursă: Repository public

01 / Comportamentul sistemului

Dovadă interactivă

Un mecanism tehnic specific proiectului, bazat pe arhitectura și contextul de implementare înregistrate.

Dovadă interactivăRate Limit - Comparație de Algoritmi Implementați de la Zero

Fixed windowBoundary burst

Sliding windowPrecise limit

Context și intenție

În loc să folosesc o bibliotecă existentă, am implementat doi algoritmi de rate limiting de la zero pentru a înțelege mecanismul real - algoritmul propriu-zis, implicațiile de stocare, convențiile de headere și deficiența subtilă care face un algoritm strict mai corect decât celălalt.

Fixed Window Counter împarte timpul în intervale discrete și menține un simplu contor per fereastră - O(1) timp și spațiu, dar vulnerabil la burst-uri la limita de fereastră, unde un client poate trimite de 2 ori mai multe cereri decât limita intenționată, sincronizându-se cu granița dintre ferestre. Sliding Window Log stochează un array de timestamp-uri per client, filtrând intrările expirate la fiecare cerere - limitare precisă fără posibilitatea de a exploata granița, cu prețul memoriei O(n) per client.

03 / Înregistrarea arhitecturii

Arhitectură

O interpretare structurată a arhitecturii înregistrate pentru acest proiect.

Înregistrarea arhitecturiiRate Limit - Comparație de Algoritmi Implementați de la Zero

Configurarea per client este definită în clients

Pipeline-ul de middleware este simplu și direct

Ambele strategii primesc un IRateLimitStorage în constructor

Citește înregistrarea completă a arhitecturii

Pipeline-ul de middleware este simplu și direct: Logger → Auth → Rate Limiter → Handler. Două rute demonstrează diferența - GET /foo folosește Fixed Window, GET /bar folosește Sliding Window.

Ambele strategii primesc un IRateLimitStorage în constructor. Interfața de stocare este deliberat minimală: get, set, increment, decrement, reset - orice backend care poate face aceste cinci operații se poate conecta.

Configurarea per client este definită în clients.ts, mapând ID-uri de client la limite per endpoint. Middleware-ul extrage ruta, caută configurarea clientului și transmite limitele specifice oricărui limitator activ.

Cum este structurat sistemul

Ambele strategii partajează aceeași interfață IRateLimitStrategy, ceea ce face schimbarea algoritmului o modificare de un singur cuvânt în definiția rutei. Backend-urile de stocare sunt la fel de interschimbabile prin IRateLimitStorage - in-memory pentru dezvoltare, Redis pentru producție și deployment-uri distribuite.

Un test dedicat de comparație creează ambele limitatoare, rulează aceeași secvență de cereri pe ambele și verifică comportamentele diferite la granița de fereastră - făcând diferența algoritmică vizibilă direct în output-ul testului.

05 / Aspecte selectate

Note de implementare selectate

Deciziile și fluxurile cu cea mai mare valoare explicativă.

Doi algoritmi de rate limiting interschimbabili (Fixed Window Counter și Sliding Window Log) în spatele unei singure interfețe IRateLimitStrategy
Backend-uri de stocare modulare prin IRateLimitStorage - in-memory (bazat pe Map) și Redis (cu setWithExpiry și management al ciclului de viață al conexiunii)
Configurare de rate limit per client, per endpoint - clienți diferiți primesc limite diferite pe rute diferite, reflectând nivelurile reale ale platformelor API
Test de comparație a strategiilor care demonstrează direct vulnerabilitatea de burst la granița de fereastră: aceeași secvență de cereri, rezultate diferite de la fiecare algoritm
Headere de răspuns standard X-RateLimit-* (Limit, Remaining, Window-Ms, Strategy) plus Retry-After la 429 - conform specificației draft IETF
Pipeline complet de middleware: Logger → Auth (Bearer token) → Rate Limiter → Handler

06 / Metrici susținute

Înregistrarea verificată a proiectului

Algoritmi Implementați: 2
Backend-uri de Stocare: 2
Dovada Burst la Graniță: ✓
Headere Conforme IETF: 4

Tehnologie în context

TypeScript, Node.js, Express.js, Redis, Jest

Vezi repository-ul sursă