Redis — cache em memória para sites e lojas
O Redis é a camada de velocidade por trás dos sites, lojas e marketplaces construídos na 4buildsite: mantém em memória (RAM) exatamente os dados que têm de ser servidos de imediato — páginas em cache, sessões, carrinhos, limites de pedidos — e responde em menos de um milissegundo. A fonte de verdade continua a ser o PostgreSQL; o Redis protege-a quando o tráfego é elevado. Está incluído e é gerido pela plataforma, sem qualquer configuração da tua parte.
O que é o Redis e porque é tão rápido
O Redis (REmote DIctionary Server) é uma base de dados in-memory de código aberto: guarda os dados na RAM e não no disco, pelo que responde em menos de um milissegundo. Na 4buildsite usamo-lo como camada de aceleração à frente do PostgreSQL — para tudo o que tem de ser servido de imediato: páginas, sessões, carrinhos e limites de pedidos.
Ao contrário de um disco, a RAM é ordens de grandeza mais rápida, e o Redis acrescenta estruturas de dados nativas (string, hash, lista, conjunto, conjunto ordenado, stream) que permitem operações complexas diretamente em memória, sem ida e volta à base principal. O processamento dos comandos é single-threaded, pelo que o comportamento é previsível e sem race conditions.
- Latência típica abaixo de 1 ms e mais de 100.000 operações por segundo num único nó
- Estruturas nativas: hashes para as sessões, sorted sets para rankings e rate limiting, streams para as filas
- Single-threaded nos comandos → comportamento previsível, sem bloqueios complexos
Cache: as tuas páginas e dados, servidos a partir da memória
A estratégia é cache-aside: o primeiro pedido lê do PostgreSQL e guarda o resultado no Redis com um TTL (tempo de vida); os pedidos seguintes vão buscá-lo diretamente à memória. Quando editas uma página, a chave é apagada de forma explícita — nunca servimos dados desatualizados por causa de um TTL às cegas.
Para um site de apresentação ou uma loja, isto significa que as listas de produtos, os menus, as páginas populares e os fragmentos de conteúdo podem ser servidos a partir da memória, sem sobrecarregar a base de dados. Nos picos (uma campanha, a Black Friday) o Redis absorve os pedidos repetidos.
- Cache-aside com invalidação explícita — sem dados desatualizados
- Guarda fragmentos de página e resultados de queries, não apenas páginas inteiras
- Protege o PostgreSQL nos picos de tráfego, reduzindo os tempos de resposta
Sessões, carrinho de compras e proteção antiabuso
As sessões de utilizador e os tokens de refresh ficam no Redis: autenticação rápida, expiração automática através do TTL e revogação imediata em todos os dispositivos quando alguém termina sessão ou muda a palavra-passe.
O carrinho de compras das lojas construídas na 4buildsite é mantido no Redis para os visitantes não autenticados — com expiração, sem inchar a base principal. É também o Redis que aplica rate limiting nos formulários de contacto e no início de sessão, com recurso a sorted sets, para travar o spam e as tentativas de força bruta antes que cheguem à base de dados.
- Armazenamento de sessões com expiração automática e revogação seletiva dos tokens
- Carrinho persistente com TTL para visitantes anónimos
- Rate limiting e antiabuso em formulários e na autenticação
Tempo real e filas de tarefas em segundo plano
O Pub/Sub e as Streams do Redis alimentam as atualizações em tempo real: um stock que desce ao vivo, uma notificação na aplicação, o estado de uma encomenda que muda — tudo sem que o visitante tenha de atualizar a página e sem polling repetido a cansar o servidor.
As tarefas pesadas (o processamento de uma imagem, a geração de uma exportação, uma sincronização) entram numa fila Redis e são executadas por workers em segundo plano, para que o visitante não tenha de esperar pelo processamento. Um mecanismo de locking distribuído garante que uma operação crítica não é executada duas vezes.
- Pub/Sub e Streams para eventos ao vivo (stock, encomendas, notificações)
- Filas de tarefas para processamentos pesados executados de forma assíncrona
- Locking distribuído para operações que não devem ser executadas duas vezes
Vantagens e limitações
Vantagens
- Resposta abaixo de 1 ms por chave, a partir da memória
- Reduz a carga sobre o PostgreSQL com muito tráfego
- Estruturas nativas para sessões, carrinho, rate limiting e rankings
- Pub/Sub e Streams para funcionalidades em tempo real, sem polling
- Filas de tarefas para processamentos pesados, sem bloquear o visitante
- Incluído e gerido pela plataforma — zero configuração da tua parte
Limitações
- Os dados ficam na RAM, que é mais cara do que o disco → não serve para volumes enormes de dados «a frio»
- É uma cache / camada auxiliar, não a fonte de verdade — os dados permanentes ficam no PostgreSQL
- A persistência (RDB/AOF) reduz, mas não elimina por completo, o risco de perder os últimos segundos num crash
- Exige uma estratégia de invalidação correta, caso contrário pode servir dados desatualizados
Veredicto breve
Usa o Redis para tudo o que tem de ser instantâneo — cache, sessões, carrinho, rate limiting, tempo real e filas de tarefas. Não o uses como repositório principal de dados; para isso continua a ser o PostgreSQL. Na 4buildsite tens os dois, combinados automaticamente: não tens de escolher nem de configurar nada.
Tabela de especificações
| Capacidade | Detalhe | Onde se usa no builder |
|---|---|---|
| Latência | < 1 ms (in-memory) | Páginas e dados em cache, a partir da memória |
| Throughput | > 100.000 ops/s por nó | Muito tráfego sem derrubar a base de dados |
| Estruturas de dados | string, hash, list, set, sorted set, stream | Sessões, carrinho, rankings, filas, rate limiting |
| Persistência | Snapshot RDB + log AOF | Recuperação rápida depois de um reinício |
| Expiração | TTL por chave | Carrinho, sessões e cache com limpeza automática |
| Tempo real | Pub/Sub + Streams | Stock ao vivo, notificações, estado da encomenda |
Redis (cache) vs. apenas base de dados
| Critério | Com Redis | Apenas PostgreSQL |
|---|---|---|
| Tempo de resposta em dados repetidos | abaixo de 1 ms, a partir da memória | dezenas de ms, query em cada pedido |
| Com muito tráfego | base protegida, escala com facilidade | base congestionada, com risco de timeouts |
| Carrinho e sessões | rápidos, com expiração automática | tabelas que crescem e sobrecarregam a base |
| Tempo real | Pub/Sub e Streams nativos | polling repetido, dispendioso |
| Filas de tarefas | nativas, simples de usar | soluções improvisadas ou inexistentes |
Perguntas frequentes
O que é o Redis, em poucas palavras?
Uma base de dados in-memory ultrarrápida, usada como camada de cache, sessões e tempo real à frente da base principal. Responde em menos de um milissegundo.
Porque não usam apenas o PostgreSQL?
O PostgreSQL é a fonte de verdade (dados duráveis), mas o Redis serve os dados repetidos em menos de um milissegundo e assume o carrinho, as sessões, o rate limiting e o tempo real, protegendo a base quando o tráfego é elevado. Os dois trabalham em conjunto.
Perco dados se o Redis falhar?
O conteúdo do site não: os dados permanentes estão no PostgreSQL. No Redis ficam apenas cache e dados temporários, e a persistência RDB/AOF reduz as perdas. Um reinício do Redis não afeta o teu site publicado.
Tenho de configurar o Redis?
Não. Está incluído e é gerido pela plataforma 4buildsite; tu beneficias das funcionalidades em tempo real sem administrar nada.
Como é que o Redis ajuda uma loja online?
Carrinho para os visitantes, listas de produtos em cache, stock atualizado ao vivo e proteção antiabuso no checkout e nos formulários — tudo sem sobrecarregar a base de dados.
O Redis ajuda no SEO e nos Core Web Vitals?
Sim, de forma indireta: tempos de resposta curtos do servidor são um dos fatores que influenciam o TTFB e, por consequência, os Core Web Vitals.