Loading content
Rate Limiting ist ein Architekturprinzip zur Begrenzung von Anfragen an Dienste oder APIs, um Überlast und Missbrauch zu verhindern. Es definiert Regeln für erlaubte Anfragefrequenzen, Backoff-Verhalten und Antwortcodes. Typische Anwendungen reichen von API-Gateways über CDN bis zu serviceinternen Controls für stabile Verfügbarkeit.
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Theoretisches Gebilde: erklärt einen Begriff, ein Prinzip oder ein Denkmodell.
Was Zusammenhänge ordnet, verbindet oder entscheidbar macht.
Rate Limiting begrenzt die Anfragefrequenz an Dienste oder APIs, um Überlast zu vermeiden und Missbrauch fair zu drosseln.
In Netzwerken wurde Rate Limiting genutzt, um die Rate gesendeter bzw. empfangener Requests an einer Schnittstelle oder in Protokoll-Komponenten zu kontrollieren; Ziel war u. a. der Schutz vor DoS-Angriffen und das Begrenzen von Web-Scraping. Im Web-Kontext wurde die Absicht über standardisierte HTTP-Signale greifbar: RFC 6585 (April 2012, IETF; M. Nottingham, R. Fielding) definiert den Statuscode 429 „Too Many Requests“ für den Fall, dass ein Client innerhalb eines Zeitfensters zu viele Requests sendet. Das RFC legt außerdem optionale Detailangaben und den Retry-After-Header fest und nennt die Regel „429 darf nicht gecached werden“.
Rate Limiting funktioniert wie eine Schutzschranke vor der eigentlichen Verarbeitung: Zuerst wird ein Zähl-Scope (wer/was zählt) und ein Zeitfenster festgelegt sowie eine Obergrenze für die erlaubte Frequenz. Bei jedem eingehenden Request bestimmt der Durchsatz-Controller anhand des Scopes den passenden Zähler, aktualisiert den Count über das Zeitfenster und vergleicht ihn mit der Grenze. Liegt der Request innerhalb des Limits, wird er an den Service weitergereicht. Überschreitet der Request die Grenze, wird er zurückgewiesen; typischerweise mit 429, ggf. plus Retry-After als Hinweis für den nächsten Versuch. In verteilten Setups hängt die Wirksamkeit davon ab, wie genau der Scope und die Zählstrategie abgebildet werden.
Eine zulässige Anfragefrequenz wird über ein definiertes Zeitfenster als Obergrenze ausgedrückt; Überschreitungen führen zur Zurückweisung.
Durchsetzung erfolgt anhand eines Schlüssels, z. B. per Auth-/Cookie-Kontext oder Ressource; das RFC beschreibt explizit nicht, wie genau gezählt oder identifiziert wird.
RFC 6585 definiert 429 „Too Many Requests“ als Signal für „zu viele Requests“; optionale Zusatzdetails können mitgeliefert werden.
Als Guidance kann Retry-After angeben, wie lange gewartet werden soll, bevor der Client erneut anfragt.
Antworten mit 429 dürfen nicht von Caches gespeichert werden.
Mehr Präzision beim Abbilden von „wer überschreitet was“ kann mehr Ressourcen beim Rate Limiter erfordern; es gibt einen Trade-off zwischen Genauigkeit und Ressourcen-Footprint.
Rate Limiting hilft, wenn Endpunkte durch hohe oder ungleich verteilte Zugriffsraten gefährdet sind—typisch an API-Gateways, vorgeschalteten Komponenten oder serviceintern. Es schafft einen erwartbaren Backoff-Pfad über 429 und optionalem Retry-After. Entscheidend sind Grenzen und Trade-offs: (1) das Ausgeben von 429 kann selbst Ressourcen kosten, daher sind Server nach RFC 6585 nicht verpflichtet, in jeder Situation 429 zu verwenden; (2) die tatsächliche Zähl- und Identifikationslogik ist deployment-spezifisch, da das RFC Details dazu offen lässt; (3) präzisere Scopes können den Betrieb des Limiters teurer machen, während zu grobe Grenzen legitimen Traffic treffen können.
Wo dieser Baustein im Themenmodell verortet ist.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.