Como usar o Redis como cache distribuído em APIs Node.js

Por que sua API Node.js precisa de um cache em memória

Quando uma aplicação web cresce, o banco de dados costuma ser o primeiro componente a sofrer com a lentidão. Cada clique de um usuário gera consultas complexas que consomem poder de processamento do disco rígido e da memória principal. Na prática, isso significa que requisições idênticas continuam recalculando os mesmos resultados repetidamente, desperdiçando recursos preciosos.

Para resolver esse gargalo, introduzimos o conceito de cache distribuído. Em vez de perguntar diretamente ao banco de dados relacional toda vez que alguém busca uma informação pública ou um perfil, a aplicação consulta uma camada intermediária ultrarrápida. Essa abordagem se assemelha a manter os itens mais vendidos na vitrine da frente de uma loja, evitando que o vendedor precise ir ao estoque no fundo do depósito a cada nova venda.

O Redis se destaca nesse cenário por armazenar todas as informações diretamente na memória RAM, o que garante tempos de resposta na casa dos milissegundos. Além disso, por ser uma ferramenta independente que roda em segundo plano, ele pode ser compartilhado por várias instâncias da sua API Node.js, mantendo os dados sincronizados em um ambiente escalável. Se você deseja aprofundar seus conhecimentos sobre o tráfego dessas informações e validar cabeçalhos, vale a pena conferir o guia sobre como usar o curl para testar APIs e headers HTTP na prática.

Configurando a conexão com o Redis em projetos Node.js

O primeiro passo prático na implementação consiste em instalar o cliente oficial ou bibliotecas populares compatíveis com o ecossistema assíncrono do Node.js. No nosso caso, utilizaremos a biblioteca ioredis, conhecida por sua estabilidade e suporte nativo a comandos avançados. Para começar, adicione a dependência ao seu projeto utilizando o gerenciador de pacotes padrão do seu ambiente de desenvolvimento.

Após a instalação, precisamos inicializar a conexão apontando para o endereço de rede onde o servidor Redis está executando. Na prática, criamos um arquivo centralizado de configuração que exporta uma instância pronta para uso em toda a aplicação. Isso evita conexões duplicadas e garante um controle unificado do ciclo de vida do cliente de cache.

const Redis = require('ioredis');

const redisClient = new Redis({
  host: '127.0.0.1',
  port: 6379,
  retryStrategy: (times) => {
    const delay = Math.min(times * 50, 2000);
    return delay;
  }
});

redisClient.on('error', (err) => {
  console.error('Erro na conexão com o Redis:', err);
});

module.exports = redisClient;

Implementando a estratégia de cache em rotas frequentes

Com a conexão estabelecida, podemos modificar as rotas da nossa API para verificar o cache antes de consultar o banco de dados principal. Essa lógica segue um padrão simples: a aplicação recebe a requisição, gera uma chave única baseada nos parâmetros recebidos e verifica se essa chave já existe no Redis. Caso exista, retornamos o dado armazenado imediatamente.

Se a chave não for encontrada — um evento conhecido na computação como cache miss —, procedemos com a consulta tradicional ao banco de dados. Logo após obter o resultado bruto, salvamos uma cópia dessa resposta no Redis acompanhada de um tempo de expiração. Dessa forma, as próximas requisições idênticas serão atendidas instantaneamente pelo cache sem sobrecarregar o sistema principal. Da mesma forma que otimizamos consultas em memória, é fundamental garantir que o banco relacional possua estruturas adequadas, conforme explicamos no artigo sobre como criar índices no PostgreSQL para acelerar buscas.

const express = require('express');
const redisClient = require('./redisClient');
const db = require('./database');

const app = express();

app.get('/api/produtos', async (req, res) => {
  const cacheKey = 'produtos:todos';

  try {
    const cachedData = await redisClient.get(cacheKey);

    if (cachedData) {
      return res.json({
        source: 'cache',
        data: JSON.parse(cachedData)
      });
    }

    const produtos = await db.query('SELECT * FROM produtos');
    
    // Expira em 60 segundos para evitar dados obsoletos
    await redisClient.set(cacheKey, JSON.stringify(produtos), 'EX', 60);

    return res.json({
      source: 'database',
      data: produtos
    });
  } catch (error) {
    console.error('Falha ao processar requisição:', error);
    res.status(500).json({ error: 'Erro interno no servidor' });
  }
});

Gerenciando estratégias de invalidação e atualização de dados

O maior desafio ao trabalhar com cache distribuído não é salvar a informação, mas sim decidir o momento correto de apagá-la ou atualizá-la. Quando um usuário altera um produto no sistema, a versão antiga armazenada no Redis continua ativa, gerando inconsistências visuais. Na prática, isso significa que precisamos implementar rotinas de invalidação sempre que ocorrer uma operação de escrita.

Existem duas abordagens principais para resolver esse problema: a expiração baseada em tempo (TTL) e a invalidação orientada a eventos. O TTL funciona como uma rede de segurança passiva, fazendo com que o dado expire automaticamente após alguns minutos. Já a invalidação orientada a eventos remove explicitamente a chave do cache logo após uma inserção, atualização ou exclusão bem-sucedida no banco de dados.

Ao combinar essas duas técnicas, garantimos que a aplicação se mantenha performática sem sacrificar a precisão das informações exibidas aos clientes. É importante lembrar que o cache deve ser tratado como um recurso volátil e descartável; caso o servidor do Redis caia inesperadamente, a API deve ser capaz de recorrer diretamente ao banco de dados sem quebrar a experiência do usuário final. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre Como testar diodo zener na placa com multímetro digital.

Considerações finais sobre resiliência e boas práticas

Utilizar o Redis como cache distribuído em APIs Node.js representa um divisor de águas na escalabilidade de sistemas modernos. A combinação de respostas rápidas com a diminuição drástica de consultas complexas ao banco de dados permite que a infraestrutura suporte picos elevados de acesso com estabilidade. No entanto, o sucesso dessa arquitetura depende diretamente de escolhas conscientes sobre o tempo de vida dos dados e de uma estratégia robusta de tratamento de falhas.

Lembre-se sempre de monitorar o consumo de memória do seu servidor de cache e de definir políticas de remoção de chaves quando a capacidade máxima for atingida. Com uma implementação limpa, monitoramento constante e rotinas eficientes de invalidação, sua aplicação estará preparada para crescer de forma sustentável e eficiente.