Redis — caching in memoria per siti e negozi
Redis è lo strato di accelerazione dietro i siti, i negozi e i marketplace costruiti su 4buildsite: tiene in memoria (RAM) i dati più richiesti — pagine in cache, sessioni, carrelli, limiti di frequenza. La fonte di verità resta PostgreSQL; Redis la protegge quando il traffico cresce. È incluso e gestito dalla piattaforma, senza alcuna configurazione da parte tua.
Che cos'è Redis e perché è così veloce
Redis (REmote DIctionary Server) è un database in memoria open source: tiene i dati nella RAM anziché su disco, quindi ha latenze molto basse. Su 4buildsite lo usiamo come strato di accelerazione davanti a PostgreSQL, per tutto ciò che deve essere letto di frequente: pagine, sessioni, carrelli e limiti di frequenza.
A differenza di un disco, la RAM è più veloce di diversi ordini di grandezza, e Redis aggiunge strutture dati native (stringa, hash, lista, insieme, insieme ordinato, stream) che permettono operazioni complesse direttamente in memoria, senza andata e ritorno verso il database principale. L'elaborazione dei comandi avviene su un solo thread, quindi il comportamento è prevedibile e privo di race condition.
- Latenza tipica sotto 1 ms e oltre 100.000 operazioni al secondo su un singolo nodo
- Strutture native: hash per le sessioni, insiemi ordinati per classifiche e rate limiting, stream per le code
- Un solo thread per i comandi → comportamento prevedibile, senza blocchi complessi
Cache: le tue pagine e i tuoi dati, letti dalla memoria
La strategia è cache-aside: la prima richiesta legge da PostgreSQL e salva il risultato in Redis con un TTL (tempo di vita); le richieste successive lo prendono direttamente dalla memoria. Quando modifichi una pagina, la chiave viene cancellata in modo esplicito: non serviamo mai dati obsoleti a causa di un TTL cieco.
Per un sito vetrina o un negozio, questo significa che gli elenchi di prodotti, i menu, le pagine più visitate e i frammenti di contenuto vengono consegnati dalla memoria anche con traffico elevato, senza sovraccaricare il database. Nei picchi (una campagna, il Black Friday) Redis assorbe le richieste ripetute.
- Cache-aside con invalidazione esplicita: nessun dato obsoleto
- Memorizza frammenti di pagina e risultati di query, non solo pagine intere
- Protegge PostgreSQL nei picchi di traffico, riducendo le letture ripetute
Sessioni, carrello e protezione dagli abusi
Le sessioni utente e i token di refresh risiedono in Redis: autenticazione, scadenza automatica tramite TTL e revoca su tutti i dispositivi quando qualcuno esce dall'account o cambia la password.
Il carrello dei negozi costruiti su 4buildsite viene tenuto in Redis per i visitatori non autenticati, con scadenza e senza gonfiare il database principale. È sempre Redis ad applicare il rate limiting sui moduli di contatto e sull'accesso, usando gli insiemi ordinati, per fermare lo spam e i tentativi a forza bruta prima che raggiungano il database.
- Archivio delle sessioni con scadenza automatica e revoca selettiva dei token
- Carrello persistente con TTL per i visitatori anonimi
- Rate limiting e protezione dagli abusi su moduli e autenticazione
Tempo reale e code di lavori in background
Il Pub/Sub e gli Stream di Redis alimentano gli aggiornamenti in tempo reale: una giacenza che cala dal vivo, una notifica nell'applicazione, lo stato di un ordine che cambia — tutto senza che il visitatore debba ricaricare la pagina e senza polling ripetuto che affatica il server.
Le attività pesanti (l'elaborazione di un'immagine, la generazione di un'esportazione, una sincronizzazione) entrano in una coda Redis e vengono eseguite da worker in background. Un meccanismo di lock distribuito garantisce che un'operazione critica non venga eseguita due volte.
- Pub/Sub e Stream per gli eventi dal vivo (giacenze, ordini, notifiche)
- Code di lavori per le elaborazioni pesanti eseguite in modo asincrono
- Lock distribuito per le operazioni che non devono essere eseguite due volte
Vantaggi e limiti
Vantaggi
- Dati in cache letti dalla memoria, con latenza molto bassa
- Riduce il carico su PostgreSQL quando il traffico è elevato
- Strutture native per sessioni, carrello, rate limiting e classifiche
- Pub/Sub e Stream per le funzioni in tempo reale, senza polling
- Code di lavori per le elaborazioni pesanti, eseguite fuori dalla richiesta
- Incluso e gestito dalla piattaforma: zero configurazione per te
Limiti
- I dati stanno nella RAM, più costosa del disco → non è adatto a volumi enormi di dati «freddi»
- È una cache, uno strato ausiliario, non la fonte di verità: i dati permanenti restano in PostgreSQL
- La persistenza (RDB/AOF) riduce, ma non elimina del tutto, il rischio di perdere gli ultimi secondi in caso di crash
- Richiede una strategia di invalidazione corretta, altrimenti può servire dati obsoleti
Verdetto in breve
Usa Redis per tutto ciò che deve essere immediato: cache, sessioni, carrello, rate limiting, tempo reale e code di lavori. Non usarlo come archivio principale dei dati; per quello resta PostgreSQL. Su 4buildsite hai entrambi, abbinati in automatico: non devi scegliere né configurare nulla.
Tabella delle specifiche
| Capacità | Dettaglio | Dove si usa nel builder |
|---|---|---|
| Latenza | < 1 ms (in memoria) | Pagine e dati letti dalla memoria |
| Capacità di elaborazione | > 100.000 operazioni al secondo per nodo | Traffico elevato con meno carico sul database |
| Strutture dati | stringa, hash, lista, insieme, insieme ordinato, stream | Sessioni, carrello, classifiche, code, rate limiting |
| Persistenza | Snapshot RDB e log AOF | Ripristino dei dati dopo un riavvio |
| Scadenza | TTL per ogni chiave | Carrello, sessioni e cache con pulizia automatica |
| Tempo reale | Pub/Sub e Stream | Giacenze dal vivo, notifiche, stato dell'ordine |
Redis (cache) a confronto con il solo database
| Criterio | Con Redis | Solo PostgreSQL |
|---|---|---|
| Tempo di risposta sui dati ripetuti | dalla memoria, con latenza molto bassa | una query a ogni richiesta, con latenza più alta |
| Con traffico elevato | database protetto, scala con facilità | il database si congestiona e rischia i timeout |
| Carrello e sessioni | con scadenza automatica | tabelle che crescono e appesantiscono il database |
| Tempo reale | Pub/Sub e Stream nativi | polling ripetuto, costoso |
| Code di lavori | native, semplici da usare | soluzioni improvvisate o inesistenti |
Domande frequenti
Che cos'è Redis, in breve?
Un database in memoria, usato come strato di cache, sessioni e tempo reale davanti al database principale. Ha latenze molto basse e alleggerisce il database principale.
Perché non usare solo PostgreSQL?
PostgreSQL è la fonte di verità (i dati durevoli), ma Redis serve i dati ripetuti dalla memoria, con latenze molto basse, e si occupa di carrello, sessioni, rate limiting e tempo reale, proteggendo il database quando il traffico cresce. I due lavorano insieme.
Perdo dati se Redis si guasta?
Non i contenuti del sito: i dati permanenti sono in PostgreSQL. In Redis restano solo cache e dati temporanei, e la persistenza RDB/AOF riduce le perdite. Un riavvio di Redis non tocca il tuo sito pubblicato.
Devo configurare io Redis?
No. È incluso e gestito dalla piattaforma 4buildsite; tu ottieni cache e funzioni in tempo reale senza amministrare nulla.
In che modo Redis aiuta un negozio online?
Carrello per i visitatori, elenchi di prodotti in cache, giacenze aggiornate dal vivo e protezione dagli abusi al momento del pagamento e sui moduli, il tutto senza appesantire il database.
Redis aiuta la SEO e i Core Web Vitals?
Sì, in modo indiretto: tempi di risposta bassi del server incidono sul TTFB e sui Core Web Vitals, segnali che contano per Google e per l'esperienza dell'utente.