Valkey, fork do Redis originado da mudança de licença há mais de dois anos, consolida-se como projeto de código aberto em crescimento. Durante o Open Source Summit Europe, a InfoQ entrevistou Madelyn Olson (AWS, membro do comitê técnico) e Viktor Söderqvist (Ericsson) para compreender a trajetória e os planos da iniciativa.
O projeto reúne 12 mantenedores e 9 membros do comitê técnico distribuídos por 8 empresas, incluindo Ericsson, AWS, Apple e Percona. Conferências comunitárias já alcançam até cem participantes, sinalizando expansão de adoção.
Infraestrutura e Performance nas Versões 8.x
As versões 8.x priorizaram fundamentação técnica. O async I/O threading elevou o throughput de aproximadamente 200 mil a 250 mil requisições por segundo para cerca de 1 milhão por processo. Diferente de arranjos anteriores de I/O-thread, a configuração agora permite reajuste em tempo de execução, possibilitando que operadores adicionem núcleos para picos de carga.
As versões 8.0 e 8.1 trouxeram otimizações de memória envolvendo key embedding e dicionário por slot. A dual-channel replication endereça pressão no servidor primário durante sincronização: dataset completo e stream de mudanças são transmitidos em paralelo, não sequencialmente, reduzindo consumo de memória.
Cluster e Modo Single-Instance: Avanços da Versão 9
A versão 9 removeu barreiras para migração ao modo cluster. O suporte a numbered databases—espaços de nomes anteriormente restritos a deployments single-instance—elimina um obstáculo significativo. Atomic slot migration resolve outro problema: em vez de mover dados chave por chave (deixando clusters parcialmente atualizados em falhas), a nova abordagem estabiliza dados e realiza transição única, garantindo migração completa ou nenhuma.
Hash-field expiration integra a versão 9 como um dos recursos mais solicitados. Deployments tipo Mastodon—múltiplos servidores sobre um cluster—exemplificam demanda, embora os desenvolvedores alertem contra interpretação como multi-tenância robusta.
Biblioteca GLIDE: Unificação de Clientes
Clientes Redis originalmente executavam tarefa simples: comunicar com nó único. Topologia de cluster, TLS, redirecionamentos, reconexões e pool de conexões tornaram comportamento mais complexo, com diferentes clientes implementando essas funções inconsistentemente.
A biblioteca GLIDE, originária de projeto AWS, centraliza lógica de conexão e topologia em núcleo Rust compartilhado, exposto através de bindings específicas de linguagem. Correções no núcleo beneficiam simultaneamente todas as linguagens. WebAssembly foi considerado, mas o time julgou abordagem prematura naquele momento. Valkey continua suportando clientes alternativos, incluindo implementações Go, para usuários satisfeitos com soluções nativas.
Trajetos Futuros: Para Além de Cache
Replicação síncrona é direção proposta para fornecer garantias de durabilidade em dados não puramente efêmeros. Tiering representa vertente paralela: manter dados quentes em memória enquanto desloca dados frios para SSD ou outro armazenamento.
A estratégia de tiering pode variar por perfil de dados. Chaves pequenas e pouco acessadas sairiam de DRAM; objetos suficientemente grandes permaneceriam em disco e seriam transmitidos diretamente à rede. Considera-se interface genérica para backends além de NVMe local, como S3 ou Postgres. Parquet foi discutido para change-data-capture ou outputs de clickstream, não como formato dinâmico para leitura e reescrita. Replicação ativa-ativa entre clusters com eventual consistency permanece ideia de longo prazo, sem comprometimento de implementação.
Segurança e Automação de Releases
O projeto investe em automação de segurança e eficiência de lançamentos. Backporting automatizado encurta tempo para preparar correções entre versões. Revisão pré-lançamento assistida por IA e testes de segurança proativa identificam problemas antes de cada release, reforçando confiabilidade operacional.
