← Voltar para publicações Esquema de arquitetura com Redis, Tomcat, WildFly e PostgreSQL

Redis como Solução de Cache para E-commerce em Cidades Médias Brasileiras

Cara Core Informática 02 de dezembro de 2025
Tempo estimado de leitura: ~10 minutos

Parte I: O Desafio do E-commerce nas Cidades do Interior

O Cenário: Campo Largo e o Brasil que Cresce Online

Campo Largo, município paranaense com aproximadamente 140 mil habitantes, a 30 km de Curitiba, representa o novo perfil de consumo digital. Cidades de médio porte (50–200 mil habitantes) impulsionam a compra online com retirada local — um comportamento que já chega a 35% das preferências em várias regiões.

Por Que a Retirada Local Importa?

O Problema Técnico Invisível

Como lidar com centenas de consultas simultâneas ao estoque quando clientes, operadores e integrações acessam ao mesmo tempo? Sem otimização: 180 usuários × 3 consultas → 540 queries/minuto a um banco relacional. Latência explode, telas travam, desistências aumentam.

A Matemática do Caos

Sem cache: tempo médio de query 200ms → usuários esperam 8–12s por tela; abandono ~40%; custos 3x maiores.

Por Que Bancos Relacionais Sofrem?

O Que Precisávamos

  1. Cache inteligente.
  2. Invalidação automática.
  3. Distribuição multi-servidor (Tomcat + WildFly).
  4. Simplicidade de manutenção.
  5. Custo baixo.

Entrou o Redis.

Parte II: Redis — A Transformação na Arquitetura

O Que É Redis?

Redis é a “geladeira” do software: dados na RAM para acesso em milissegundos (contra centenas em disco). Resposta instantânea para leituras quentes.

Comparação de Alternativas

Solução Prós Contras Decisão
MemcachedSimples, rápidoSem persistência, primitivo
HazelcastDistribuído, Java-nativePesado, complexo
EhCacheFácil embutirNão compartilha entre servidores
RedisRápido, leve, Pub/Sub, TTLServidor extra

Arquitetura Implementada

Arquitetura simplificada

Fluxo: Usuários acessam aplicação (Tomcat/WildFly) que consulta Redis. Em HIT responde em 2ms; em MISS consulta PostgreSQL, atualiza cache. Eventos Pub/Sub de retirada invalidam chaves mantendo consistência.

Request → App → Redis (HIT 95%) → 2ms
                  ↘ (MISS 5%) → PostgreSQL 200ms ↘ atualiza cache
Pub/Sub: retirada → mensagem → invalidação distribuída (<50ms)

3 Pilares

TTL por tipo de dado
Mapa 15s, KPIs 120s, Lead time 300s, Sessão 1800s
Pub/Sub
Sincroniza invalidação entre Tomcat e WildFly em milissegundos
Fallback
Redis caiu? Busca banco direto; funcionalidade preservada

Exemplo de Lógica (Pseudo-Java)

try {
  var cache = redis.get("estoque:mapa");
  if (cache != null) return cache; // HIT ~2ms
} catch (RedisConnectionException e) {
  logger.warn("Redis indisponível - fallback DB");
}
var data = db.query("SELECT * FROM posicao WHERE tenant_id=1");
redis.set("estoque:mapa", data, 15); // TTL 15s
return data; // MISS ~200ms

Números Antes vs Depois

Gráfico: Impacto do Redis (Baseline=100)

Visualização comparativa dos principais indicadores antes (100) e depois (redução percentual) da adoção do Redis.

Latência média
100%
7%
Latência pico
100%
4%
Queries/min
100%
5%
Abandono
100%
19%
CPU banco
100%
15%

Os valores "Depois" mostram o percentual do original (ex.: latência média agora é ~7% do valor anterior).

Melhorias: latência média −93%, pico −96%, queries/min −95%, abandono −81%, CPU −84%.

Impacto no Negócio

Custos e ROI

Lições Principais

  1. Cache útil já com >100 usuários simultâneos.
  2. Defasagem de 10–30s é aceitável para 90% dos casos.
  3. Comece pequeno (estoque) e expanda.
  4. Hit rate monitorado guia otimizações.
  5. Documente TTLs e critérios de invalidação.

Epílogo: O Futuro do E-commerce no Interior

Cidades médias como Campo Largo, Várzea Grande e Maricá sustentam o crescimento do e-commerce com modelos híbridos: compra digital, retirada física. Arquiteturas enxutas com Redis permitem experiência de grande varejista com orçamento de operação média, escalando 10x sem reescrever núcleo.

Se sua operação tem picos previsíveis, muitas consultas de estoque e orçamento limitado — cache não é luxo, é necessidade.

Sobre o CaraCore Hub

CaraCore Hub é a plataforma logística da Cara Core Informática focada em retirada local e estoque em tempo quase real.

Recursos:

Tecnologias: Java 17, Jakarta EE 10, PostgreSQL 16, Redis 7, Bootstrap 5, REST APIs.

Apresentação pública: chmulato.github.io/caracore-hub
Código fonte proprietário e privado — Cara Core Informática.

Hashtags

#Redis #Cache #Ecommerce #RetiradaLocal #Performance #Escalabilidade #CaraCoreHub #CaraCoreInformática #TTL #PubSub

Contato

🤝 Gostou do conteúdo?
Siga para mais arquitetura prática e otimização de operações digitais.
Seguir no LinkedIn

Artigo técnico | 02 de dezembro de 2025 | CaraCore Hub v2.4
© 2025 Cara Core Informática. Todos os direitos reservados.