Redis: Caching, Sessioni e Code Real-Time nel Nostro Stack
Quando CRM81 ha iniziato a crescere e LetsAI doveva gestire centinaia di job AI in parallelo, ci serviva qualcosa di più veloce del database. Redis è diventato il collante invisibile del nostro stack: cache dei dati più richiesti, sessioni utente, code di lavoro e notifiche real-time. Ecco come lo usiamo davvero.
Caching Intelligente: Da 800ms a 12ms sulle Query Più Frequenti
CRM81 ha una dashboard che mostra statistiche aggregate: numero di deal aperti, valore totale pipeline, attività recenti, performance del team. Ogni volta che un utente apre la dashboard, il sistema deve fare 6-8 query su PostgreSQL con GROUP BY, JOIN e subquery. Il risultato? 800ms di attesa prima di vedere i numeri. Moltiplicato per 50 utenti che aprono la dashboard ogni mattina alle 9:00, il database era in ginocchio. La soluzione è stata semplice: Redis come cache layer. Quando un utente carica la dashboard, il backend controlla prima se i dati aggregati sono in cache (TTL di 60 secondi). Se sì, risponde in 12ms. Se no, esegue le query, salva il risultato in Redis, e risponde. Le scritture (nuovo deal, aggiornamento contatto) invalidano chirurgicamente solo le chiavi cache coinvolte. Il pattern che usiamo è cache-aside con invalidazione event-driven. Non invalidiamo tutta la cache a ogni scrittura — solo le chiavi specifiche. Se aggiorni il valore di un deal, invalidiamo solo la chiave della pipeline totale, non quella delle attività recenti. Questo ci dà un hit rate del 94% sulla dashboard, che significa che 94 richieste su 100 non toccano mai PostgreSQL. Abbiamo anche implementato un sistema di cache warming: un job che pre-popola la cache ogni mattina alle 8:55, cinque minuti prima del picco di accessi. Risultato: anche il primo utente della giornata vede la dashboard in 12ms.
Pub/Sub e Code di Lavoro: Il Motore Real-Time di LetsAI
LetsAI è la nostra piattaforma che permette alle aziende di creare workflow AI personalizzati. Un utente può lanciare un job che analizza 500 documenti, genera report e invia notifiche — tutto in background. Il problema: come gestire centinaia di job concorrenti senza perderne nessuno, e come notificare l'utente in tempo reale dello stato di avanzamento? Redis risolve entrambi i problemi. Per le code di lavoro, usiamo Redis Lists con il pattern BRPOPLPUSH (ora BLMOVE in Redis 7). I worker Node.js estraggono job dalla coda, li elaborano, e li spostano in una coda "completati". Se un worker crasha a metà elaborazione, il job resta nella coda di processing e viene ri-assegnato dopo un timeout. Zero job persi, anche sotto carico pesante. Per le notifiche real-time, usiamo Redis Pub/Sub. Quando un job cambia stato (in_progress, completed, failed), il worker pubblica un messaggio su un canale Redis. Il server Node.js è sottoscritto a quel canale e inoltra l'aggiornamento al browser dell'utente via WebSocket. La latenza end-to-end è sotto i 50ms: l'utente vede la barra di progresso aggiornarsi quasi istantaneamente. Abbiamo valutato RabbitMQ e Apache Kafka come alternative. RabbitMQ è più robusto per code mission-critical, ma aggiunge un servizio separato da gestire. Kafka è sovradimensionato per i nostri volumi. Redis era già nel nostro stack per il caching, quindi usarlo anche per le code ha significato zero infrastruttura aggiuntiva.
Sessioni e Rate Limiting: Redis Come Guardiano delle API
Le sessioni utente di CRM81 e LetsAI sono gestite interamente su Redis. Quando un utente effettua il login, creiamo un hash Redis con i dati della sessione (user_id, ruolo, permessi, timestamp login) e settiamo un TTL di 8 ore. Il session ID va nel cookie HTTP-only. Ad ogni richiesta, il middleware Node.js controlla la sessione su Redis in meno di 1ms — molto più veloce di una query al database. Il vantaggio architetturale è enorme: se scaliamo orizzontalmente con più istanze Node.js dietro un load balancer, le sessioni funzionano automaticamente perché sono centralizzate su Redis, non in memoria locale. Un utente può essere servito da qualsiasi istanza senza problemi di sticky sessions. Abbiamo anche implementato rate limiting con Redis per proteggere le nostre API. Usiamo il pattern sliding window con ZADD e ZRANGEBYSCORE: ogni richiesta aggiunge un timestamp al sorted set dell'utente, e contiamo quante richieste ci sono nella finestra degli ultimi 60 secondi. Se il conteggio supera il limite (100 req/min per utenti standard, 500 per enterprise), l'API risponde con 429 Too Many Requests. Tutto questo avviene in 0.5ms grazie a Redis. Un consiglio pratico: configurate maxmemory-policy su allkeys-lru. Se Redis esaurisce la memoria, inizia a eliminare automaticamente le chiavi meno usate di recente. Meglio perdere una sessione di cache che crashare. In due anni non abbiamo mai avuto un'emergenza Redis.
Servizi Correlati
Scopri come applichiamo queste tecnologie nei nostri progetti enterprise.
Interessato?
Contattaci per ricevere un preventivo personalizzato.
Securvita S.r.l. — i3k.eu