Como escolher a ferramenta ideal

Objetivos

Nesta aula você vai:

• Estruturar uma checklist de decisão para bancos em memória
• Comparar Redis, Valkey, Memcached e opções gerenciadas em nuvem
• Alinhar escolha técnica a custo operacional e maturidade da equipe

Introdução

"Qual banco em memória devo usar?" é pergunta frequente em arquitetura de software — e raramente tem resposta universal. A ferramenta ideal depende do formato dos dados, das garantias exigidas, do orçamento de RAM, da equipe que opera e do ecossistema já presente na empresa.

Esta aula oferece um framework de decisão em camadas, não um veredito dogmático. Ao final, você deve conseguir justificar uma escolha para stakeholders técnicos e de negócio.

Conteúdo

Dimensões de avaliação

Antes de comparar produtos, documente requisitos:

Preencher essa tabela com o projeto real elimina 80% das opções incorretas.

Árvore de decisão simplificada

Precisa apenas de cache simples chave-valor, sem estruturas ricas?
├── Sim → Memcached ou Redis/Valkey em modo cache puro
└── Não → Precisa de filas duráveis, pub/sub, sorted sets?
    ├── Sim → Redis ou Valkey (compatível)
    └── Não → Avaliar também KeyDB, Hazelcast, ou cache na CDN

Precisa alta disponibilidade automática em produção?
├── Sim → Redis/Valkey Cluster ou Sentinel; ou ElastiCache/Memorystore
└── Não → Instância única com backup pode bastar em homologação

Restrição de licença SSPL (Redis Ltd.)?
├── Sim → Valkey (fork Linux Foundation, BSD)
└── Não → Redis open source ou enterprise conforme contrato

Comparativo resumido das opções do módulo

Redis gerenciado (AWS ElastiCache, Azure Cache, Google Memorystore): reduz burden operacional; custo maior; versões e features dependem do provedor.

Valkey: escolha natural quando se busca compatibilidade Redis com governança open source neutra — detalhado no curso 3 deste módulo.

Anti-padrões a evitar

1. Cache como único banco sem backup para dados que não podem ser reconstruídos
2. TTL único para tudo — dados estáticos e voláteis na mesma política
3. Objetos gigantes serializados em uma chave — fragmenta memória e bloqueia rede
4. Hot keys sem shard ou local cache — um único key vira gargalo de CPU/rede
5. Escolher por hype sem medir hit rate e latência p99 na carga real

Integração com o restante da stack

A ferramenta em memória raramente vive isolada. Considere:

• ORM e invalidação: quem invalida o cache após UPDATE no Postgres?
• Observabilidade: métricas de hit/miss exportadas para Prometheus?
• Segurança: TLS, ACL, rede privada — Redis sem senha em VPC exposta é incidente esperado
• Custo: RAM em cloud é cara; dimensionar maxmemory e eviction evita surpresa na fatura

Exemplos práticos

Checklist aplicada a um SaaS B2B com API REST e PostgreSQL:

Prova de conceito local antes de contratar managed:

docker run -d --name redis-poc -p 6379:6379 redis:7-alpine
redis-cli PING

Se o POC validar latência e comandos necessários, suba o mesmo cliente (ex.: ioredis, Lettuce) contra o endpoint gerenciado em staging.

Resumo

• Escolha ferramenta em memória a partir de requisitos explícitos, não de popularidade isolada.
• Memcached brilha em cache volátil simples; Redis/Valkey cobrem ecossistema completo de estruturas e persistência.
• Licenciamento, HA e operação managed são critérios de negócio tão importantes quanto throughput.
• Documente anti-padrões e integração com banco primário, observabilidade e segurança.
• Este módulo aprofunda Redis (curso 2), Valkey (curso 3) e Memcached (curso 4) para refinar a decisão tomada aqui.