Redis — caching in-memory pentru site-uri și magazine instant
Redis este stratul de viteză din spatele site-urilor, magazinelor și marketplace-urilor construite pe 4buildsite: ține în memorie (RAM) exact datele care trebuie servite instant — pagini cache-uite, sesiuni, coșuri, limite de rată — și răspunde în sub o milisecundă. Sursa de adevăr rămâne PostgreSQL; Redis o protejează la trafic mare și face experiența să pară instantanee. Este inclus și gestionat de platformă, fără nicio configurare din partea ta.
Ce este Redis și de ce este atât de rapid
Redis (REmote DIctionary Server) este o bază de date in-memory open-source: ține datele în RAM, nu pe disc, deci răspunde în sub o milisecundă. Pe 4buildsite îl folosim ca strat de accelerare în fața PostgreSQL — pentru tot ce trebuie servit instant: pagini, sesiuni, coșuri și limite de rată.
Spre deosebire de un disc, RAM-ul este cu ordine de mărime mai rapid, iar Redis adaugă structuri de date native (string, hash, listă, set, sorted set, stream) care permit operații complexe direct în memorie, fără drum dus-întors la baza principală. Procesarea comenzilor este single-threaded, deci comportamentul este predictibil și fără race conditions.
- Latență tipică sub 1 ms și peste 100.000 de operații pe secundă pe un singur nod
- Structuri native: hash-uri pentru sesiuni, sorted set pentru topuri și rate limiting, stream pentru cozi
- Single-threaded pe comenzi → comportament predictibil, fără blocaje complexe
Caching: paginile și datele tale, servite instant
Strategia este cache-aside: prima cerere citește din PostgreSQL și salvează rezultatul în Redis cu un TTL (timp de viață); cererile următoare îl iau direct din memorie. Când editezi o pagină, cheia este ștearsă explicit — nu servim niciodată date învechite printr-un TTL orb.
Pentru un site de prezentare sau un magazin, asta înseamnă că listele de produse, meniurile, paginile populare și fragmentele de conținut se livrează în milisecunde chiar și la trafic mare, fără să suprasolicite baza de date. La vârfuri (o campanie, Black Friday) Redis absoarbe cererile repetate și ține site-ul rapid.
- Cache-aside cu invalidare explicită — fără date stale
- Memorează fragmente de pagină și rezultate de query, nu doar pagini întregi
- Protejează PostgreSQL la vârfuri de trafic, reducând timpii de răspuns
Sesiuni, coș de cumpărături și protecție anti-abuz
Sesiunile de utilizator și token-urile de refresh stau în Redis: autentificare rapidă, expirare automată prin TTL și revocare instant pe toate dispozitivele atunci când cineva se deloghează sau schimbă parola.
Coșul de cumpărături din magazinele construite pe 4buildsite este ținut în Redis pentru vizitatorii neautentificați — rapid, cu expirare, fără să umfle baza principală. Tot Redis aplică rate limiting pe formularele de contact și pe login, folosind sorted sets, ca să oprească spam-ul și încercările de forță brută înainte să ajungă la baza de date.
- Session store cu expirare automată și revocare selectivă a token-urilor
- Coș persistent cu TTL pentru vizitatori anonimi
- Rate limiting și anti-abuz pe formulare și autentificare
Timp real și cozi de joburi în fundal
Redis Pub/Sub și Streams alimentează actualizările în timp real: un stoc care scade live, o notificare în aplicație, statusul unei comenzi care se schimbă — totul fără ca vizitatorul să dea refresh și fără polling repetat care obosește serverul.
Sarcinile grele (procesarea unei imagini, generarea unui export, o sincronizare) intră într-o coadă Redis și sunt rulate de workeri în fundal, ca vizitatorul să primească răspuns imediat. Un mecanism de locking distribuit garantează că o operație critică nu rulează de două ori.
- Pub/Sub și Streams pentru evenimente live (stoc, comenzi, notificări)
- Cozi de joburi pentru procesări grele rulate asincron
- Locking distribuit pentru operații care nu trebuie să ruleze de două ori
Avantaje și limitări
Avantaje
- Răspuns sub 1 ms: datele cache-uite se servesc practic instant
- Scade dramatic încărcarea pe PostgreSQL la trafic mare
- Structuri native pentru sesiuni, coș, rate limiting și topuri
- Pub/Sub și Streams pentru funcții în timp real, fără polling
- Cozi de joburi pentru procesări grele, fără să blocheze vizitatorul
- Inclus și gestionat de platformă — zero configurare pentru tine
Limitări
- Datele stau în RAM, care este mai scump decât discul → nu este pentru volume uriașe de date „la rece"
- Este un cache / strat auxiliar, nu sursa de adevăr — datele permanente rămân în PostgreSQL
- Persistența (RDB/AOF) reduce, dar nu elimină complet, riscul de a pierde ultimele secunde la un crash
- Necesită o strategie de invalidare corectă, altfel poate servi date învechite
Verdict scurt
Folosește Redis pentru tot ce trebuie să fie instant — caching, sesiuni, coș, rate limiting, timp real și cozi de joburi. Nu îl folosi ca depozit principal de date; pentru asta rămâne PostgreSQL. Pe 4buildsite ai ambele, potrivite automat: nu trebuie să alegi sau să configurezi nimic.
Tabel de specificații
| Capabilitate | Detaliu | Unde se folosește în builder |
|---|---|---|
| Latență | < 1 ms (in-memory) | Pagini și date servite instant |
| Throughput | > 100.000 ops/s pe nod | Trafic mare fără să cadă baza |
| Structuri de date | string, hash, list, set, sorted set, stream | Sesiuni, coș, topuri, cozi, rate limiting |
| Persistență | Snapshot RDB + log AOF | Recuperare rapidă după un restart |
| Expirare | TTL per cheie | Coș, sesiuni și cache cu auto-curățare |
| Timp real | Pub/Sub + Streams | Stoc live, notificări, status comandă |
Redis (cache) vs. doar bază de date
| Criteriu | Cu Redis | Doar PostgreSQL |
|---|---|---|
| Timp de răspuns la date repetate | sub 1 ms, din memorie | zeci de ms, query la fiecare cerere |
| La trafic mare | baza protejată, scalează ușor | baza se aglomerează, riscă timeout-uri |
| Coș și sesiuni | rapide, cu expirare automată | tabele care cresc și încarcă baza |
| Timp real | Pub/Sub și Streams native | polling repetat, costisitor |
| Cozi de joburi | native, simple de folosit | soluții improvizate sau inexistente |
Întrebări frecvente
Ce este Redis, pe scurt?
O bază de date in-memory ultra-rapidă, folosită ca strat de cache, sesiuni și timp real în fața bazei principale. Răspunde în sub o milisecundă și face site-ul să pară instantaneu.
De ce nu folosiți doar PostgreSQL?
PostgreSQL este sursa de adevăr (date durabile), dar Redis servește datele repetate în sub o milisecundă și preia coșul, sesiunile, rate limiting-ul și timpul real, protejând baza la trafic mare. Cele două lucrează împreună.
Pierd date dacă Redis cade?
Nu conținutul site-ului: datele permanente sunt în PostgreSQL. În Redis stau doar cache și date temporare, iar persistența RDB/AOF reduce pierderile. Un restart al Redis nu îți afectează site-ul publicat.
Trebuie să configurez eu Redis?
Nu. Este inclus și gestionat de platforma 4buildsite; tu beneficiezi de viteză și de funcțiile în timp real fără să administrezi nimic.
Cum ajută Redis un magazin online?
Coș rapid pentru vizitatori, liste de produse cache-uite, stoc actualizat live și protecție anti-abuz la checkout și pe formulare — toate fără să încarce baza de date.
Redis ajută la SEO și Core Web Vitals?
Da, indirect: timpii de răspuns mici îmbunătățesc TTFB și Core Web Vitals, semnale care contează atât pentru Google, cât și pentru experiența utilizatorului și pentru motoarele AI.