Distributed Systems

De Poortwachter van je Microservices Landschap

Wanneer een bedrijf zijn backend opdeelt in tientallen microservices, exposeer je al snel een wirwar aan interne diensten naar de buitenwereld. Als je mobiele app of frontend rechtstreeks verbinding zou maken met al die afzonderlijke services, krijg je te maken met gruwelijke uitdagingen: CORS-problemen, verspreide authenticatie-logica, dubbele SSL-certificaten en het ontbreken van centrale bescherming tegen overbelasting. De architectonische oplossing hiervoor is de **API Gateway**.

De API Gateway fungeert als de enige centrale ingang (Reverse Proxy) voor al het inkomende verkeer van buitenaf. Het handelt SSL-terminatie af, verifieert JWT-tokens voordat ze de microservices bereiken, doet load-balancing, en implementeert een van de meest kritieke beveiligingsmechanismen voor openbare API’s: **Rate Limiting**.

Waarom Rate Limiting Cruciaal Is

Zonder rate limiting kan een kwaadwillende gebruiker (of een slecht geschreven script met een oneindige loop) jouw API overspoelen met honderdduizenden verzoeken per seconde, waardoor al je databases en services onderuit gaan in een klassieke Denial of Service (DoS). Rate limiting beperkt het aantal verzoeken dat een specifieke gebruiker, IP-adres of API-sleutel mag uitvoeren binnen een tijdsvenster (bijv. maximaal 100 verzoeken per minuut).

Token Bucket vs. Leaky Bucket Algoritme

Om rate limiting efficiënt en bliksemsnel te berekenen (vaak in een in-memory cache zoals Redis), maken architecten gebruik van specifieke wiskundige algoritmes. De twee beroemdste zijn de **Token Bucket** en de **Leaky Bucket**.

• Token Bucket Algoritme: Stel je een emmer voor met een vaste maximale capaciteit (bijv. 10 tokens). De emmer wordt continu, met een vaste snelheid, bijgevuld met nieuwe tokens (bijv. 2 tokens per seconde). Telkens wanneer een client een API-verzoek doet, probeert de gateway één token uit de emmer te pakken. Is de emmer vol? Dan worden extra tokens weggegooid. Is de emmer leeg? Dan wordt het verzoek geweigerd met een 429 Too Many Requests HTTP-status. Dit algoritme is populair omdat het **bursts** toestaat: een gebruiker die een tijdje niks heeft gedaan, mag in één klap tien verzoeken achter elkaar afvuren zolang er tokens in de emmer zitten.
• Leaky Bucket Algoritme: Dit algoritme focust zich op een constante uitgaande stroom. Verzoeken komen binnen in een emmer (queue). De emmer lekt verzoeken met een volstrekt constante, onwrikbare snelheid naar de backend-services. Komen er te te veel verzoeken binnen en stroomt de emmer over? Dan worden de overige verzoeken direct gedropt. Dit beschermt kwetsbare backend-databases tegen elke vorm van verkeerspiek, maar voelt voor gebruikers soms trager aan omdat bursts worden afgevlakt.

Het slim inrichten van API Gateways en rate limiting beschermt je infrastructuur en garandeert een stabiele uptime. Ontdek meer over API-strategieën op Frankwatching.

 

Volgende: Service Mesh Architectuur (Istio vs. Linkerd): Mutual TLS en Traffic Shifting
Kennisbank overzicht