Wie würdest du einen Rate Limiter für eine öffentliche API entwerfen?

Wähl zuerst die Dimension des Limits, meist den API Key statt der IP, dann einen Algorithmus: Token Bucket, um Bursts zu erlauben, Sliding Window für gleichmäßigere Durchsetzung. Halt die Zähler in einem gemeinsamen Store wie Redis, damit alle Instanzen sich einig sind, mit atomaren Inkrementen und Ablauf. Gib 429 mit einem Retry-After-Header und dem Restkontingent zurück, und fail open, wenn der Limiter selbst nicht verfügbar ist, damit er deine API nicht mit runterreißt.

Ich fange damit an, worauf ich limitiere, und bei einer öffentlichen API ist das der API Key, nicht die IP, weil Kunden hinter einem NAT sich nicht gegenseitig ausknocken sollen. Dann der Algorithmus. Token Bucket ist mein Default, weil er einem Client erlaubt, ein bisschen zu bursten, was dazu passt, wie echte Integrationen sich verhalten: Sie wachen auf, feuern zwanzig Requests und sind dann eine Stunde still. Ein Sliding Window Log ist präziser, speichert aber mehr pro Key. Wichtig ist, dass der Zähler geteilt sein muss, denn wenn jede meiner sechs Instanzen ihren eigenen Zähler führt, ist das echte Limit sechsmal so hoch wie angekündigt, also Redis mit atomarem Inkrement und Ablauf, oder ein kleines Lua-Skript, wenn ich Prüfung und Dekrement zusammen brauche. Bei Ablehnung gebe ich 429 mit Retry-After und dem Restkontingent in den Headern zurück, denn ein Client, der sauber zurückstecken kann, hört auf, mich zu hämmern. Und ich mache fail open, denn ein Limiter, der die API mit runterreißt, hat mehr Schaden angerichtet als der Missbrauch, den er verhindert hat.