Patronen voor API-snelheidsbeperking en schaalbaarheid · Les

Beleid voor verkeerspieken en coulanceperiodes

Implementeer beleid dat tijdelijke verkeerspieken of coulanceperiodes toestaat om de gebruikerservaring te verbeteren zonder de stabiliteit in gevaar te brengen.

Les 2 van 411 stappen

Beleid voor verkeerspieken en coulanceperiodes is een gratis Patronen voor API-snelheidsbeperking en schaalbaarheid-les op CoddyKit. Dit is les 2 van 4. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Patronen voor API-snelheidsbeperking en schaalbaarheid. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Patronen voor API-snelheidsbeperking en schaalbaarheid bevat in totaal 4 lessen.

Flexibele limieten: bursts en respijt

Welkom! API's moeten vaak flexibel zijn. Soms kan een strikte rate limit te beperkend aanvoelen voor gebruikers, zelfs als die de API beschermt.

In deze les bekijken we twee geavanceerde beleidsregels: bursting en respijtperiodes. Hiermee bied je een soepelere gebruikerservaring zonder de stabiliteit van het systeem in gevaar te brengen.

Wat is bursting?

Met bursting kan een API-gebruiker gedurende korte tijd tijdelijk boven de normale snelheid komen. Zie het als een tijdelijk 'tegoed' of een tijdelijke 'toegestane marge' boven het standaardquotum.

Het is nuttig om plotselinge, kortdurende verkeerspieken op te vangen.
Het helpt voorkomen dat legitieme gebruikers bij ongebruikelijke activiteit onmiddellijk worden geblokkeerd.
De burstcapaciteit is meestal beperkt in omvang en duur.

Waarom tijdelijke bursts toestaan?

Stel je een gebruikerstoepassing voor die normaal 60 aanvragen per minuut doet (1 aanvraag per seconde). Wat als de toepassing:

Initiële gegevens moet laden: bij het opstarten 10 aanvragen in 2 seconden moet doen;
Een batch moet verwerken: na een gebruikersactie 5 bestanden tegelijk moet uploaden;
Van netwerkproblemen moet herstellen: enkele aanvragen snel opnieuw moet verzenden.

Zonder bursting kunnen deze legitieme acties de rate limit direct bereiken, wat tot een slechte gebruikerservaring leidt.

Een burstbeleid ontwerpen

Een burstbeleid definieert twee belangrijke aspecten:

Burstcapaciteit: hoeveel extra aanvragen zijn toegestaan boven de normale limiet? (bijvoorbeeld 5 extra aanvragen).
Vulsnelheid of duur van de burst: hoe snel wordt de burstcapaciteit aangevuld, of hoe lang is de burst beschikbaar? (bijvoorbeeld: de burstcapaciteit wordt na 1 minuut aangevuld of is 10 seconden geldig).

Dit wordt vaak gecombineerd met een token-bucketalgoritme, waarbij de omvang van de bucket groter is dan de normale limiet en tijdelijke overschrijdingen mogelijk zijn.

Code: eenvoudige bursttoestemming

Deze vereenvoudigde Java-code demonstreert hoe een bursttoestemming kan werken. Er worden enkele extra aanvragen toegestaan, zelfs nadat de 'normale' limiet is bereikt.

public class Main {
  private static int requestsProcessed = 0;
  private static int burstAllowance = 3; // Extra requests allowed for burst
  private static int normalLimit = 5; // Normal requests allowed per window

  public static boolean checkRequestWithBurst() {
    if (requestsProcessed < normalLimit) {
      requestsProcessed++;
      System.out.println("Request allowed (normal). Total: " + requestsProcessed);
      return true;
    } else if (burstAllowance > 0) {
      burstAllowance--;
      requestsProcessed++; // Still count as a processed request
      System.out.println("Request allowed (using burst). Burst left: " + burstAllowance);
      return true;
    } else {
      System.out.println("Request denied (limit & burst exhausted).");
      return false;
    }
  }

  public static void main(String[] args) {
    System.out.println("Testing burst policy (5 normal + 3 burst requests):");
    for (int i = 0; i < 10; i++) { // Try 10 requests
      checkRequestWithBurst();
    }
  }
}

Respijtperiodes begrijpen

Een respijtperiode is een kort tijdsvenster dat direct nadat een API-gebruiker de rate limit heeft overschreden, aan die gebruiker wordt toegekend. In plaats van onmiddellijk te worden geblokkeerd, mag de gebruiker mogelijk nog enkele aanvragen doen of krijgt die kort de tijd om zich aan te passen.

Het verzacht de gevolgen van het bereiken van een limiet.
Het geeft clients de kans om geleidelijk minder aanvragen te doen.
Het wordt vaak gebruikt met de HTTP-statuscode 429 Too Many Requests.

Hoe respijtperiodes werken

Wanneer een client de rate limit overschrijdt, antwoordt de server meestal met statuscode 429 Too Many Requests en een Retry-After-header.

Met een respijtperiode:

De client bereikt de limiet.
De server antwoordt met 429 en schakelt voor die client over naar de 'respijtmodus'.
Gedurende zeer korte tijd (bijvoorbeeld 1 à 2 seconden) of voor 1 à 2 extra aanvragen kunnen volgende aanvragen nog steeds worden verwerkt, of krijgen ze een andere status (bijvoorbeeld 200 OK met een waarschuwing).
Na de respijtperiode wordt de limiet weer strikt afgedwongen.

Code: eenvoudige logica voor een respijtperiode

Dit Java-voorbeeld simuleert een respijtperiode. Nadat de normale limiet is bereikt, wordt nog één extra aanvraag toegestaan voordat verdere pogingen worden geweigerd.

public class Main {
  private static int requestsProcessed = 0;
  private static boolean inGracePeriod = false;
  private static int graceRequestsRemaining = 1; // How many grace requests allowed
  private static int normalLimit = 3; // Normal requests allowed

  public static boolean checkRequestWithGrace() {
    if (requestsProcessed < normalLimit) {
      requestsProcessed++;
      System.out.println("Request allowed (normal). Total: " + requestsProcessed);
      return true;
    } else if (!inGracePeriod) {
      // First time hitting limit, activate grace
      inGracePeriod = true;
      System.out.println("Limit hit. Entering grace period.");
      // Fall through to check graceRequestsRemaining
    }

    if (inGracePeriod && graceRequestsRemaining > 0) {
      graceRequestsRemaining--;
      requestsProcessed++; // Still count total processed
      System.out.println("Request allowed (grace). Grace left: " + graceRequestsRemaining);
      return true;
    } else {
      System.out.println("Request denied (limit & grace exhausted).");
      return false;
    }
  }

  public static void main(String[] args) {
    System.out.println("Testing grace period policy (3 normal + 1 grace request):");
    for (int i = 0; i < 6; i++) { // Try 6 requests
      checkRequestWithGrace();
    }
  }
}

Balans vinden: voor- en nadelen

Zowel bursting als respijtperiodes zijn bedoeld om de gebruikerservaring te verbeteren, maar ze brengen afwegingen met zich mee:

Voordelen: soepelere gebruikerservaring, minder abrupte blokkeringen, betere afhandeling van uitzonderingssituaties en veerkrachtigere clients.
Nadelen: kunnen de serverbelasting iets verhogen, kunnen worden misbruikt als ze niet zorgvuldig worden geconfigureerd en voegen complexiteit toe aan de logica van de rate limiter.

Zorgvuldig afstemmen is essentieel om ervoor te zorgen dat deze beleidsregels de stabiliteit van de API verbeteren in plaats van verminderen.

Oefening met beleidsregels

Denk na over een API die 100 aanvragen per minuut toestaat. Een clienttoepassing verstuurt soms 150 aanvragen binnen een periode van 10 seconden door een batchbewerking die door de gebruiker is gestart, en keert daarna terug naar normaal gebruik.

Beantwoord dit in de interactieve les

Burst en respijt: belangrijkste punten

We hebben twee krachtige beleidsregels geleerd om rate limiting gebruiksvriendelijker te maken:

Bursting: staat tijdelijke, gecontroleerde pieken in het aantal aanvragen boven de normale snelheid toe.
Respijtperiodes: bieden een kort 'vergevingsvenster' nadat een limiet is bereikt en verzachten zo de gevolgen van onmiddellijke blokkeringen.

Als je deze beleidsregels zorgvuldig implementeert, vind je een balans tussen het beschermen van je API en het bieden van een robuuste, flexibele ervaring aan je gebruikers.

Gratis beginnen

Leer Patronen voor API-snelheidsbeperking en schaalbaarheid met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen: 12
Lessen: 48

Gratis beginnen met leren Bekijk de volledige cursus

Veelgestelde vragen

Is de les “Beleid voor verkeerspieken en coulanceperiodes” gratis?

Ja — de volledige tekst van “Beleid voor verkeerspieken en coulanceperiodes” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus Patronen voor API-snelheidsbeperking en schaalbaarheid wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus Patronen voor API-snelheidsbeperking en schaalbaarheid bevat in totaal 4 lessen.

Wat leer ik in “Beleid voor verkeerspieken en coulanceperiodes”?

Implementeer beleid dat tijdelijke verkeerspieken of coulanceperiodes toestaat om de gebruikerservaring te verbeteren zonder de stabiliteit in gevaar te brengen. Je oefent met Patronen voor API-snelheidsbeperking en schaalbaarheid door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met Patronen voor API-snelheidsbeperking en schaalbaarheid te beginnen?

Ervaring vooraf is niet nodig. Patronen voor API-snelheidsbeperking en schaalbaarheid op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 2 van 4.

Hoe lang duurt de les “Beleid voor verkeerspieken en coulanceperiodes”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over Patronen voor API-snelheidsbeperking en schaalbaarheid?

Ja. Elke les over Patronen voor API-snelheidsbeperking en schaalbaarheid bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

Throttling versus rate limiting uitgelegd
Beleid voor verkeerspieken en coulanceperiodes
Limieten aan clientzijde versus serverzijde
Het juiste rate-limitingalgoritme kiezen

← Terug naar Patronen voor API-snelheidsbeperking en schaalbaarheid