Valkey: O sucessor open source do Redis
Quando utilizar Valkey
Analise cenários em que o Valkey é a melhor escolha para novos projetos ou substituições.
Nesta aula você vai
- Definir critérios de negócio e técnicos para adoção do Valkey em novos projetos
- Comparar cenários em que Redis Ltd. ainda pode ser a escolha racional
- Elaborar plano de migração gradual de Redis para Valkey em sistemas legados
Quando utilizar Valkey
Objetivos
Nesta aula você vai:
- Aplicar framework de decisão Valkey vs Redis vs serviço gerenciado
- Reconhecer sinais organizacionais que favorecem fork BSD (compliance, cloud, custo)
- Esboçar estratégias de migração com zero downtime e rollback
Introdução
Saber que Valkey existe e que é compatível com Redis não responde à pergunta operacional: devo usar? A resposta depende de licenciamento corporativo, provedor de cloud, dependência de módulos enterprise e fase do ciclo de vida do sistema — greenfield, brownfield ou contrato Redis Enterprise ativo.
Esta aula oferece critérios práticos, não evangelismo. Em muitos cenários, Valkey é escolha padrão em 2025+; em outros, permanecer no ecossistema Redis Ltd. ou em Memcached ainda é racional.
Conteúdo
Adote Valkey quando…
1. Licenciamento e compliance exigem BSD/OSI
Empresas com política de software livre, distribuidores de pacotes ou produtos embarcados que não aceitam SSPL beneficiam-se de Valkey sem renegociar contrato.
2. Você usa ou planeja serviço gerenciado multi-cloud
AWS ElastiCache, Google Cloud Memorystore e outros passaram a oferecer engine Valkey com mesmo modelo operacional — alinhamento natural entre dev local (container Valkey) e produção gerenciada.
3. Greenfield sem módulos Redis proprietários
Novo microsserviço com cache-aside, sessão, rate limit e streams: começar em Valkey evita débito de migração futura.
4. Fork comunitário com roadmap transparente
Times que preferem governança Linux Foundation e contribuição multi-vendor a roadmap single-vendor.
5. Custo de licença Redis Enterprise é proibitivo
Features enterprise da Redis Ltd. (Active-Active geo, certos SLAs) têm preço — Valkey + engenharia interna pode custar menos em escala, com trade-off de esforço.
Permaneça ou avalie Redis Ltd. quando…
1. Contrato Redis Enterprise ativo
Active-Active cross-region, suporte 24/7 contratual, módulos integrados — switching cost alto até fim do contrato.
2. Dependência crítica de módulos sem equivalente maduro em Valkey
RediSearch em produção com queries complexas — mapear alternativa (OpenSearch, módulo Valkey) antes de migrar.
3. Time padronizado em Redis Cloud oficial
Se ferramentas, billing e runbooks estão 100% na console Redis Ltd. e SSPL não é obstáculo jurídico interno.
4. Feature exclusiva Redis necessária em curto prazo
Compare release notes — se bloqueante e sem workaround, adiar migração é válido.
Árvore de decisão executiva
| Pergunta | Sim → | Não → |
|---|---|---|
| SSPL é problema legal/comercial? | Valkey | Redis ainda viável |
| Usa apenas core + cliente padrão? | Migração fácil | PoC módulos |
| Cloud gerenciada oferece Valkey na região? | Alinhar dev/prod | Self-host Valkey ou aguardar |
| Precisa Redis Enterprise geo-active? | Avaliar custo Valkey DIY | Redis Ltd. |
Estratégias de migração
Big bang (janela de manutenção):
- Snapshot RDB do Redis
- Restore em Valkey
- Alterar endpoint na aplicação
- RTO baixo se dataset pequeno; risco concentrado
Dual-write temporário:
- Aplicação escreve Redis e Valkey
- Lê de Valkey com fallback Redis
- Desliga Redis após validação — complexo, raro
Réplica + failover (preferido em HA):
- Valkey como réplica de Redis (fase transitória) ou dump/restore com replicação inicial
- Promove Valkey; redireciona clientes
- Testar offset de replicação
Strangler em microsserviços:
- Migrar serviço a serviço
- Instância Valkey compartilhada ou dedicada por bounded context
- Rollback por serviço isolado
Operação pós-adoção
- Fixar versão em imagem (
valkey/valkey:8.x) e renovar com changelog - Monitorar métricas com dashboards adaptados (nome
valkeyem exporters) - Participar de RFCs se sua empresa depende criticamente do projeto
- Documentar decisão arquitetural (ADR) para auditoria futura
Exemplos práticos
ADR resumido (template):
# ADR-042: Engine de cache em memória — Valkey
## Contexto
Cache-aside no order-service; sem módulos Redis Ltd.
## Decisão
Valkey 8 em ElastiCache; cliente Lettuce inalterado.
## Consequências
+ Licença BSD; alinhamento AWS
- Equipe deve acompanhar divergência de features vs Redis 8
Docker Compose para dev alinhado à prod:
services:
valkey:
image: valkey/valkey:8-alpine
ports:
- "6379:6379"
command: valkey-server --appendonly yes
Rollback plan:
- Manter snapshot Redis RDB por 7 dias
- Feature flag
CACHE_BACKEND=redis|valkey - Runbook: reverter DNS em < 5 min
Resumo
- Valkey é escolha forte para novos projetos, compliance BSD e clouds que o adotam como engine padrão.
- Redis Ltd. permanece relevante para enterprise features, contratos e módulos sem paridade imediata.
- Migração segura combina testes automatizados, canary e rollback explícito.
- Decisão deve constar em ADR — não apenas troca de imagem Docker.
- Este módulo fecha o arco: fundamentos (curso 1), Redis profundo (curso 2), Valkey (curso 3) e Memcached (curso 4) para cache minimalista.