Talvez você não precise de Redis

• O Redis é uma das tecnologias com melhor reputação na indústria de tecnologia
  • É uma tecnologia excelente, muito bem projetada, e não há nada de errado com ela em si, mas talvez nem sempre seja necessário
• Ao longo de mais de 10 anos, em 3 empresas, vi o mesmo padrão:
  • Surgia um problema e o Redis parecia adequado, mas na prática ele não melhorava a situação nem resolvia o problema de raiz
  • Era apenas complexidade pela complexidade

Primeiro caso: experiência na Tantan

• A Tantan é o segundo maior aplicativo de namoro da China e opera de 50 a 100 servidores de banco de dados de alto desempenho baseados em PostgreSQL
• Cada servidor é fragmentado por ID de usuário, de modo que os dados de um usuário específico ficam armazenados em apenas um servidor
• Situação do problema
  • Surgiu a necessidade de armazenar a contagem de swipes e atualizá-la rapidamente
  • No início, avaliou-se que armazenar isso no Redis seria o mais apropriado
  • A equipe configurou tudo pensando que algumas poucas instâncias de Redis de alto desempenho seriam suficientes
• Reavaliação e solução
  • A equipe discutiu uma alternativa: gravar diretamente no PostgreSQL em vez de usar Redis
  • Como a carga nos servidores PostgreSQL já era alta, previa-se que a carga adicional seria insignificante
  • Mesmo após armazenar no PostgreSQL, não houve queda de desempenho, e a adoção do Redis se mostrou desnecessária

Segundo caso: experiência na Bannerflow

• Contexto
  • A Bannerflow é uma plataforma de criação e publicação de anúncios
  • Em um novo microsserviço, decidiu-se adotar Redis para dar suporte à publicação de anúncios em redes sociais como o Facebook
• Situação do problema
  • Como a carga era muito menor do que na Tantan, não estava claro se a adoção do Redis era realmente necessária
  • Depois que o desenvolvedor inicial saiu, não havia mais ninguém capaz de explicar claramente por que o Redis havia sido adotado
• Resultado
  • Como a carga era baixa, o Redis não era realmente necessário
  • Chegou-se à conclusão de que, no longo prazo, o melhor seria remover o Redis

Terceiro caso: experiência na MAJORITY

• Contexto
  • A MAJORITY é uma empresa de fintech que adotou Redis para armazenar em cache os resultados de chamadas a APIs externas
  • O Redis foi introduzido para armazenar em cache dados de consulta de localização, acelerando o processamento e reduzindo custos
• Situação do problema
  • Os mesmos dados também eram armazenados no banco de dados (Azure SQL)
  • Previa-se que, mesmo substituindo as chamadas ao Redis por chamadas ao banco, quase não haveria aumento de carga
  • Pensou-se em manter o Redis por causa da necessidade de tratamento de lock, mas o Azure SQL era plenamente capaz de lidar com isso
• Resultado
  • Chegou-se à conclusão de que a adoção do Redis era desnecessária
  • Foi definido um plano de migração para usar Azure SQL em vez de Redis

Conclusão

• Os três casos ocorreram em domínios, stacks técnicos e condições de carga diferentes
• O ponto em comum foi a adoção desnecessária de Redis
• Antes de adotar Redis, é preciso considerar com cuidado a necessidade real e os ganhos de desempenho
• Recomendação da palestra 'Choose Boring Technology', de Dan McKinley

[iolothebard]

Independentemente de você usar Redis ou não, inserir uma camada de cache entre o domínio e a persistência (com implementação padrão em bypass) não é overengineering de forma alguma. Logging, dados falsos, depuração, profiling, talvez cache de verdade…

[nodelay]

+1 Eu também concordo. Só de adicionar uma camada já se cria uma margem, abrindo espaço para resolver inúmeras coisas.

[galadbran]

Parece menos uma questão de haver algum problema com o Redis e mais uma visão de que, se só o banco de dados já é suficiente, por que introduzir um componente extra e aumentar a carga de manutenção.
Como a explicação é um pouco resumida, acho que vale receber isso mais como um ponto de vista que também merece ser considerado.
Também há situações em que adotar um cache com Redis, mantendo a lógica da aplicação simples, pode ser a melhor escolha,
então é preciso decidir de acordo com o contexto.

[zinisuni]

Caí no título. rsrs Concordo~~

[GN⁺]

Comentários do Hacker News

• Em 2015, enquanto trabalhava na Uber, houve uma tentativa de mudar a divisão geográfica baseada em CEP para um modelo baseado em hexágonos

  • Em vez de dividir a cidade em dezenas de CEPs, a ideia era dividi-la em centenas de milhares de hexágonos e gerar regiões dinamicamente
  • O primeiro lançamento aconteceu em Phoenix, e a equipe virou a noite para escalar o sistema de preços dinâmicos
  • O lançamento global foi adiado
  • Havia muitos engenheiros que gostavam de Redis
  • O serviço de preços era baseado em Redis e processava milhões de requisições
  • Era caro e também havia problemas de escalabilidade
  • Com melhorias no algoritmo, foi possível calcular regiões dinâmicas de várias cidades em uma única máquina
  • Um engenheiro chamado Isaac implementou e colocou isso em produção durante um fim de semana

• Houve debate sobre o uso excessivo de Redis

  • Redis é ótimo, mas seu uso traz latência de rede e overhead de serialização
  • Se os dados já estiverem particionados, um hashmap comum pode ser melhor
  • Em Java, há opções como ConcurrentHashMap, Guava Caches e Caffeine Caches
  • Implementar cache local quase sempre é mais rápido do que usar a rede
  • Redis tende a ser usado em excesso

• A cultura de uso do Redis não evoluiu tanto quanto sua popularidade

  • Redis suporta várias estruturas de dados, e conforme a cultura técnica da empresa amadurece, mais padrões podem ser aprendidos
  • É uma pena não haver uma coletânea de padrões do Redis

• A questão não é Redis versus não Redis, mas trabalhar com dados que não serializam bem

  • Contadores, feeds de notícias e mensagens de chat podem ser mais eficientes com Redis
  • Na maioria dos casos, MySQL também dá conta

• O desenvolvimento de software frequentemente tende a repetir a forma como outras pessoas fazem as coisas

  • Começou com Memcached e evoluiu para Redis
  • Há uma tendência de usar cache para evitar a complexidade dos bancos de dados
  • Bancos de dados continuam complexos e difíceis

• Redis é o único "servidor de estruturas de dados" realmente pronto para produção

  • É útil quando várias instâncias precisam acessar o mesmo serviço

• Talvez você nem precise de cache

  • Houve experiências em que o foco foi melhorar a arquitetura sem introduzir cache

• A API do Redis é excelente, mas há riscos operacionais

  • É bom como cache, mas não é confiável como armazenamento de dados de produção

• É surpreendente a tendência de não recomendar o uso de Redis

  • Redis ainda oferece ótimas estruturas de dados e desempenho

• Redis serve bem como cache temporário, mas deixa a desejar para transações ou armazenamento distribuído

  • É preciso aprender sobre os problemas de locks distribuídos