Jede öffentlich erreichbare API braucht Rate Limiting — die Begrenzung, wie viele Anfragen ein Aufrufer in einem Zeitraum stellen darf. Ohne sie ist eine API drei Risiken ausgesetzt: Überlastung durch einzelne Nutzer, Missbrauch durch Angreifer und unfaire Ressourcenverteilung zwischen Kunden. Rate Limiting ist damit kein optionales Sicherheitsextra, sondern Grundausstattung jeder ernsthaften SaaS-API. Dieser Beitrag erklärt die Mechanik und die Designentscheidungen.
Wovor Rate Limiting schützt
Drei Bedrohungen adressiert Rate Limiting gleichzeitig. Erstens Stabilität: Ein fehlerhafter Client, der in einer Schleife tausende Anfragen pro Sekunde sendet, kann ohne Limit das ganze System für alle lahmlegen. Zweitens Sicherheit: Brute-Force-Angriffe auf Anmeldeendpunkte und Scraping-Versuche werden durch Limits deutlich erschwert. Drittens Fairness: In einem Multi-Tenant-System darf ein einzelner Kunde nicht die Ressourcen verbrauchen, die allen zustehen. Ein gutes Rate-Limiting-Design balanciert diese drei Ziele.
Die gängigen Algorithmen
Mehrere Verfahren haben sich etabliert. Der Fixed Window zählt Anfragen pro festem Zeitfenster — einfach, aber anfällig für Lastspitzen an den Fenstergrenzen. Der Sliding Window glättet das, indem er ein gleitendes Zeitfenster betrachtet. Der Token Bucket ist der vielseitigste: Ein Eimer füllt sich kontinuierlich mit Tokens bis zu einem Maximum, jede Anfrage verbraucht ein Token, und ist der Eimer leer, wird abgelehnt. Der Token Bucket erlaubt kurze Lastspitzen (Bursts) bis zur Eimergrösse, während er die durchschnittliche Rate begrenzt — genau das Verhalten, das die meisten APIs wollen. Der Leaky Bucket ist die Variante, die einen gleichmässigen Abfluss erzwingt.
Limits sinnvoll bemessen
Die Höhe der Limits ist eine Produktentscheidung, keine rein technische. Staffeln Sie Limits typischerweise nach Plan-Stufe — höhere Tarife bekommen höhere Limits, was zugleich ein Monetarisierungshebel ist. Setzen Sie unterschiedliche Limits für unterschiedliche Endpunkt-Klassen: günstige Lese-Operationen vertragen höhere Limits als teure Schreib- oder Rechenoperationen. Sicherheitskritische Endpunkte wie die Anmeldung bekommen besonders strenge Limits. Beginnen Sie eher grosszügig und ziehen Sie nach, statt legitime Nutzer von Anfang an auszubremsen — zu enge Limits erzeugen Frust und Supportlast.
Identifikation des Aufrufers
Rate Limiting braucht einen Schlüssel, an dem es zählt. Bei authentifizierten APIs ist das der API-Key oder die Mandanten-ID — die saubere Lösung, weil sie pro Kunde fair begrenzt. Bei nicht authentifizierten Endpunkten bleibt oft nur die IP-Adresse, die aber ungenau ist (mehrere Nutzer hinter einer IP, oder ein Angreifer mit vielen IPs). Kombinieren Sie wo möglich mehrere Signale. Im Multi-Tenant-Kontext ist der Mandantenbezug entscheidend: Begrenzen Sie pro Mandant, damit ein Kunde nicht die Kapazität eines anderen verbraucht.
Gute Fehler kommunizieren
Ein abgelehnter Request soll dem Client klar sagen, was los ist. Der Standard ist der HTTP-Statuscode 429 (Too Many Requests), begleitet von Headern, die das Limit transparent machen: das erlaubte Kontingent, der verbleibende Rest und der Zeitpunkt des Zurücksetzens. Besonders wichtig ist der Retry-After-Header, der dem Client sagt, wie lange er warten soll. Eine gut dokumentierte, vorhersehbare Rate-Limiting-Antwort erlaubt es Clients, sich korrekt zu verhalten — etwa mit exponentiellem Backoff zu warten —, statt blind weiter anzufragen und die Lage zu verschärfen.
Verteilte Umsetzung
In einer skalierten Architektur mit mehreren Instanzen reicht ein lokaler Zähler pro Server nicht, weil ein Aufrufer dann auf jedem Server sein volles Kontingent hätte. Die gängige Lösung ist ein zentraler, schneller Zählspeicher — typischerweise ein In-Memory-Datastore —, auf den alle Instanzen zugreifen. Achten Sie auf atomare Operationen, damit gleichzeitige Anfragen den Zähler korrekt führen. Für sehr hohe Lasten gibt es approximative Verfahren, die etwas Genauigkeit gegen Performance tauschen — für die meisten SaaS ist der zentrale Zähler aber der richtige Kompromiss.
Fazit
Rate Limiting schützt Stabilität, Sicherheit und Fairness zugleich. Wählen Sie einen Algorithmus, der zu Ihrem Lastprofil passt — der Token Bucket ist für die meisten APIs die beste Wahl —, bemessen Sie die Limits gestaffelt nach Plan und Endpunkt-Klasse, begrenzen Sie pro Mandant, und kommunizieren Sie abgelehnte Anfragen sauber über 429 mit aussagekräftigen Headern. Setzen Sie das Zählen in skalierten Systemen zentral und atomar um. Wer Rate Limiting früh und durchdacht einbaut, verhindert die Klasse von Vorfällen, die sich sonst erst im schlimmsten Moment zeigt.
Rate Limiting und KI-Endpunkte
Eine besondere Rolle spielt Rate Limiting bei Endpunkten, die im Hintergrund teure Operationen auslösen — allen voran Aufrufe an Sprachmodelle. Hier begrenzt das Rate Limiting nicht nur die Last, sondern direkt die Kosten: Jeder Aufruf kostet abrechnungsrelevante Tokens, und ein unbegrenzter oder missbräuchlich genutzter KI-Endpunkt kann eine erhebliche Rechnung verursachen. Setzen Sie für solche Endpunkte deshalb besonders durchdachte Limits, idealerweise gekoppelt an ein Nutzungskontingent pro Plan, und überwachen Sie ungewöhnliche Muster, die auf Missbrauch hindeuten.
Kombinieren Sie das Rate Limiting in diesen Fällen mit einer Beobachtung der tatsächlichen Kosten, nicht nur der Anfragezahl. Zwei Anfragen können sehr unterschiedliche Kosten verursachen, je nachdem, wie viel sie verarbeiten. Ein reines Zählen der Anfragen greift dann zu kurz; ein kostenbewusstes Kontingent, das den tatsächlichen Verbrauch berücksichtigt, schützt Ihre Marge besser. Rate Limiting wird so vom reinen Stabilitäts- zum Kostensteuerungsinstrument — gerade in KI-getriebenen Produkten ein entscheidender Hebel.