Redis 8.8: array nativi e rate limiting INCREX

Redis 8.8 è diventato GA questa settimana, e due delle novità interessano chiunque lo esegua dietro un'API. Il punto principale è un tipo di dato Array nativo, contribuito dal creatore di Redis Salvatore Sanfilippo. Per anni i team hanno simulato collezioni ordinate e indicizzabili con liste o sorted set. Ora esiste una struttura dedicata, così si può aggregare ed eseguire operazioni posizionali sul server invece di recuperare i dati sul client e iterarli. L'altra novità è INCREX, un comando window-counter che combina INCR, controllo dei limiti e scadenza in un'unica operazione atomica. In parole semplici, «100 richieste al minuto» è ora un unico comando invece di uno script Lua scritto a mano o un'attenta sequenza di comandi multipli.

C'è altro sotto il cofano: notifiche per sottochiavi dei campi hash, un comando XNACK che permette ai consumer degli stream di restituire messaggi bloccati, e un ciclo di ottimizzazioni delle prestazioni che include il porting di alcuni percorsi critici in Rust e l'attivazione della link-time optimization per le build x86_64. Più le solite correzioni di sicurezza e bug. Ma il tipo array e INCREX sono le modifiche che i team noteranno per prime.

Ecco la nostra opinione. INCREX è quello da guardare con attenzione. Abbiamo revisionato molti codebase in cui il rate limiting era uno script Lua scritto di fretta e che nessuno ha toccato da allora. Quegli script funzionano finché non smettono di farlo: un off-by-one nella matematica della finestra, un TTL che non viene mai impostato al primo hit, una race condition sotto carico che lascia passare un burst. Dal nostro lavoro con PHP e Docker nella costruzione di API per clienti enterprise, il rate limiting è una di quelle cose che sembra banale e in modo silenzioso non lo è. Un singolo comando atomico che gestisce il contatore, il limite e la scadenza elimina un'intera categoria di quei bug.

Detto questo, non buttare via il codice funzionante il primo giorno. Un comando nativo aiuta solo se si passa davvero a 8.8 e gli si dà fiducia in produzione. Se sei già su Redis 8.x e il tuo rate limiting è in Lua personalizzato, prototipa INCREX in staging, sottoponilo a pattern di traffico reale e confronta il comportamento ai bordi della finestra prima di fare il passaggio. Se sei su una versione precedente di Redis, considerala come una ragione per pianificare l'aggiornamento, non per farlo un venerdì pomeriggio.

Il tipo array conta di più per i workload read-heavy e di tipo analytics. Quando costruiamo app cloud-native su AWS, il killer della latenza raramente è Redis stesso. Sono i round trip. Ogni «recupera la lista, filtra sul client, rimanda una parte» è un salto di rete che paghi per ogni richiesta. Le operazioni posizionali lato server eliminano questo problema. Abbiamo visto lo stesso pattern penalizzare i team mobile: nei nostri progetti iOS e Android nativi, specialmente nelle app offline-first nel settore sanitario e IoT, un backend chiacchierino scarica la batteria e rende la sincronizzazione lenta sulle reti instabili. Fare di più in una singola chiamata lato server è un vantaggio reale quando il client è su un treno in galleria.

Una nota dal lato della sicurezza. Durante i nostri penetration test, e nella configurazione di Cloudflare per la protezione DDoS, trattiamo il rate limiting a livello applicativo e la protezione perimetrale come due livelli distinti, non come sostituti. INCREX rende il livello applicativo più pulito. Non sostituisce il rate limiting perimetrale davanti alla tua origine. Se l'unico throttle vive in Redis, un attaccante che esaurisce il connection pool non raggiunge mai il codice che lo chiama. Mantieni entrambi i livelli.

Quindi cosa dovresti fare concretamente questa settimana? Trova il tuo codice di rate limiting. Che si tratti di uno script Lua, un pacchetto middleware, o qualche riga copiata da un post di blog anni fa, leggilo di nuovo e verifica che faccia quello che pensi sotto carico concorrente. Che tu adotti INCREX o meno, quell'audit vale più dell'aggiornamento stesso. Il rilascio di un database è un buon pretesto per guardare le cose che hai smesso di controllare.

Trattiamo 8.8 come trattiamo qualsiasi minor release di un database per un cliente: leggiamo il changelog, annotiamo le correzioni di sicurezza, testiamo le funzionalità che ci interessano in staging, e pianifichiamo l'aggiornamento con cura. Il tipo array nativo e INCREX sono davvero utili. La disciplina nell'adottarli è ciò che mantiene la produzione noiosa, il che è esattamente come la vogliamo.

Se il rate limiting artigianale o un layer Redis chiacchierino suona familiare, parliamone.