Capitol activStudiu de caz
Studiu de caz / 03
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.
01 / Comportamentul sistemului
Un mecanism tehnic specific proiectului, bazat pe arhitectura și contextul de implementare înregistrate.
Î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
O interpretare structurată a arhitecturii înregistrate pentru acest proiect.
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.
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
Deciziile și fluxurile cu cea mai mare valoare explicativă.
06 / Metrici susținute
TypeScript, Node.js, Express.js, Redis, Jest
Vezi repository-ul sursă