Redis 8.8 hat endlich native Arrays und einen eingebauten Rate-Limiter. Das sollten Sie damit anfangen.

Redis 8.8 ist diese Woche als GA-Version erschienen, und zwei der Neuerungen sind für alle relevant, die Redis hinter einer API betreiben. Das Highlight ist ein nativer Array-Datentyp, der vom Redis-Gründer Salvatore Sanfilippo beigesteuert wurde. Jahrelang haben Teams geordnete, indexierbare Collections mit Listen oder Sorted Sets nachgebaut. Jetzt gibt es eine dedizierte Datenstruktur dafür – Sie können damit Aggregationen und positionsbasierte Operationen direkt auf dem Server durchführen, anstatt Daten zum Client zu übertragen und dort zu iterieren. Das andere Highlight ist INCREX, ein Fensterzähler-Befehl, der INCR, Bereichsprüfung und Ablaufzeit in einer einzigen atomaren Operation vereint. Konkret bedeutet das: „100 Anfragen pro Minute“ ist jetzt ein einziger Befehl – kein handgeschriebenes Lua-Skript und kein aufwendiger Mehrbefehlsablauf mehr.

Unter der Haube gibt es noch mehr: Subkey-Benachrichtigungen für Hash-Felder, einen XNACK-Befehl, mit dem Stream-Consumer feststeckende Nachrichten zurückgeben können, sowie eine Runde Performanceoptimierungen – darunter die Portierung einiger Hot Paths nach Rust und die Aktivierung von Link-Time Optimization für x86_64-Builds. Dazu kommen die üblichen Sicherheits- und Bugfixes. Doch der Array-Typ und INCREX sind die Änderungen, die den meisten Teams als erstes auffallen werden.

Unsere Einschätzung: INCREX ist das Feature, das Sie sich genau ansehen sollten. Wir haben viele Codebasen geprüft, in denen Rate Limiting ein Lua-Skript war, das jemand hastig geschrieben hat und das seitdem niemand mehr angefasst hat. Solche Skripte funktionieren – bis sie es nicht mehr tun: ein Off-by-One im Fensterzählalgorithmus, ein TTL, der beim ersten Treffer nie gesetzt wird, eine Race Condition unter Last, die einen Burst durchschlüpfen lässt. Aus unserer PHP- und Docker-Arbeit beim Aufbau von APIs für Enterprise-Kunden wissen wir: Rate Limiting gehört zu den Dingen, die trivial wirken und es heimlich nicht sind. Ein einzelner atomarer Befehl, der Counter, Grenze und Ablaufzeit übernimmt, beseitigt eine ganze Kategorie solcher Fehler.

Trotzdem sollten Sie funktionierenden Code nicht von Tag eins an herausreißen. Ein nativer Befehl hilft nur, wenn Sie tatsächlich auf 8.8 migrieren und ihm in der Produktion vertrauen. Wenn Sie bereits Redis 8.x nutzen und Ihr Rate Limiting auf benutzerdefiniertem Lua basiert, implementieren Sie INCREX als Prototyp in der Staging-Umgebung, spielen Sie echte Traffic-Muster darauf ein, und vergleichen Sie das Verhalten an den Fenstergrenzen, bevor Sie umstellen. Wenn Sie eine ältere Redis-Version verwenden, nehmen Sie das als Anlass, das Upgrade zu planen – nicht es an einem Freitagnachmittag durchzuführen.

Der Array-Typ ist vor allem für leseintensive und analyseorientierte Workloads relevant. Wenn wir Cloud-Native-Apps entwickeln auf AWS, ist Redis selbst selten der Latenzkiller. Es sind die Round Trips. Jedes „Liste holen, auf dem Client filtern, Teil zurücksenden“ ist ein Netzwerkhop, den Sie bei jeder Anfrage bezahlen. Serverseitige positionsbasierte Operationen vermeiden das. Wir haben dasselbe Muster bei mobilen Teams beobachtet: In unseren nativen iOS- und Android-Projekten, insbesondere bei Offline-First-Apps im Gesundheitswesen und IoT, leert ein gesprächiges Backend den Akku und lässt die Synchronisation in schlechten Netzwerken träge wirken. Mehr in einem einzigen serverseitigen Aufruf zu erledigen ist ein echter Gewinn, wenn der Client gerade in einem Zug durch einen Tunnel fährt.

Ein Hinweis aus der Sicherheitsperspektive. Bei unseren Pentesting-Aufträgen und bei der Konfiguration von Cloudflare zum DDoS-Schutz betrachten wir Rate Limiting auf Anwendungsebene und Edge-Schutz als zwei verschiedene Schichten – nicht als Ersatz füreinander. INCREX macht die Anwendungsschicht sauberer. Es ersetzt nicht das Rate Limiting am Edge vor Ihrem Origin. Wenn Ihr einziger Drosselungsmechanismus in Redis liegt, erreicht ein Angreifer, der Ihren Connection Pool erschöpfen kann, nie den Code, der ihn aufruft. Behalten Sie beide Schichten bei.

Was sollten Sie also konkret diese Woche tun? Finden Sie Ihren Rate-Limiting-Code. Ob es ein Lua-Skript, ein Middleware-Paket oder ein paar Zeilen ist, die vor Jahren aus einem Blogbeitrag kopiert wurden – lesen Sie ihn noch einmal und prüfen Sie, ob er unter gleichzeitiger Last das tut, was Sie erwarten. Ob Sie INCREX einsetzen oder nicht: Dieses Audit ist mehr wert als das Upgrade selbst. Ein Datenbankrelease ist ein guter Anlass, sich die Dinge wieder anzusehen, die man nicht mehr überprüft.

Wir behandeln 8.8 so, wie wir jedes kleinere Datenbankrelease für einen Kunden behandeln: Changelog lesen, Sicherheitsfixes notieren, die relevanten Features in Staging testen und das Upgrade bewusst einplanen. Der native Array-Typ und INCREX sind wirklich nützlich. Die Disziplin bei ihrer Einführung ist das, was die Produktion langweilig hält – und genau so mögen wir es.

Wenn Ihnen handgeschriebenes Rate Limiting oder ein gesprächiges Redis-Layer bekannt vorkommen, sprechen Sie uns an.