Puede que no necesites Redis

• Redis es una de las tecnologías con mejor reputación en la industria tecnológica
  • Es una tecnología excelente y muy bien diseñada, y no es que tenga fallas en sí misma, pero puede que no siempre sea necesaria
• Durante más de 10 años, en 3 empresas distintas, vi el mismo patrón:
  • Surgía un problema y Redis parecía encajar, pero en realidad no mejoraba la situación ni resolvía el problema de fondo
  • Solo añadía complejidad por el simple hecho de añadir complejidad

Primer caso: experiencia en Tantan

• Tantan es la segunda app de citas más grande de China y opera entre 50 y 100 servidores de base de datos de alto rendimiento basados en PostgreSQL
• Cada servidor está particionado por ID de usuario, por lo que los datos de un usuario específico se almacenan en un solo servidor
• La situación del problema
  • Surgió el requisito de almacenar la cantidad de "swipes" y actualizarla rápidamente
  • Al principio se consideró que guardarlo en Redis era lo adecuado
  • Se pensó que bastarían unos pocos servidores Redis de alto rendimiento y se avanzó con la configuración
• Reevaluación y solución
  • Dentro del equipo se discutió la opción de guardar los datos directamente en PostgreSQL en lugar de Redis
  • Como la carga en los servidores PostgreSQL ya era alta, se estimó que la carga adicional sería mínima
  • Incluso después de guardarlo en PostgreSQL no hubo degradación del rendimiento, y adoptar Redis resultó innecesario

Segundo caso: experiencia en Bannerflow

• Contexto
  • Bannerflow es una plataforma de creación y publicación de anuncios
  • Se decidió introducir Redis en un nuevo microservicio para dar soporte a la publicación de anuncios en redes sociales como Facebook
• La situación del problema
  • Dado que la carga era considerablemente menor que en Tantan, no estaba claro si realmente hacía falta introducir Redis
  • Después de que el desarrollador inicial se fuera, no quedó nadie que pudiera explicar con claridad por qué se había adoptado Redis
• Resultado
  • Redis no era realmente necesario porque la carga era baja
  • Se llegó a la conclusión de que, a largo plazo, lo mejor era eliminar Redis

Tercer caso: experiencia en MAJORITY

• Contexto
  • MAJORITY es una empresa fintech que introdujo Redis para cachear los resultados de llamadas a APIs externas
  • Redis se adoptó para cachear datos de búsqueda de ubicación, acelerar el procesamiento y reducir costos
• La situación del problema
  • Los mismos datos también se almacenaban en la base de datos (Azure SQL)
  • Se estimó que incluso si se reemplazaban las llamadas a Redis por llamadas a la base de datos, el aumento de carga sería mínimo
  • Se quería seguir usando Redis porque era necesario manejar bloqueos (lock), pero Azure SQL podía encargarse de eso sin problema
• Resultado
  • Se concluyó que introducir Redis era innecesario
  • Se estableció un plan para migrar de Redis a Azure SQL

Conclusión

• Los tres casos ocurrieron en dominios, stacks tecnológicos y condiciones de carga diferentes
• Lo que tenían en común era la adopción innecesaria de Redis
• Antes de introducir Redis, hay que considerar a fondo si realmente se necesita y qué beneficios de rendimiento aporta
• Se recomienda la charla de Dan McKinley, "Choose Boring Technology"

[iolothebard]

Más allá de si usas Redis o no, interponer una capa de caché entre el dominio y la persistencia —con una implementación base de bypass— no es para nada sobreingeniería. Sirve para logging, datos falsos, depuración, profiling y, quizás, caché real…

[nodelay]

+1 Yo también estoy de acuerdo. Con solo agregar una capa más, ya se crea margen, y eso te da espacio para resolver muchísimas cosas.

[galadbran]

Parece que, más que haber un problema con Redis, el enfoque es preguntarse por qué introducir un componente adicional y aumentar la carga de administración si solo con la base de datos es suficiente.
Como lo explica de forma bastante breve, conviene tomarlo más bien como una perspectiva que también vale la pena considerar.
También puede haber situaciones en las que sea mejor incorporar una caché de Redis para mantener simple la lógica de la aplicación,
así que habrá que elegir según el contexto.

[zinisuni]

El título sí me atrapó, jaja. Estoy de acuerdo~~

[GN⁺]

Opiniones de Hacker News

• Cuando trabajaba en Uber en 2015, intentaron cambiar una partición geográfica basada en códigos postales por un enfoque basado en hexágonos

  • En lugar de dividir una ciudad en unas cuantas decenas de códigos postales, la dividían en cientos de miles de hexágonos y generaban zonas de forma dinámica
  • El primer lanzamiento fue en Phoenix, y el equipo se desveló para escalar el sistema de precios por demanda
  • El lanzamiento global se retrasó
  • Había muchos ingenieros a quienes les encantaba Redis
  • El servicio de precios estaba basado en Redis y procesaba millones de solicitudes
  • Era costoso y también tenía problemas de escalabilidad
  • Mejoraron el algoritmo para poder calcular zonas dinámicas de varias ciudades en una sola máquina
  • Un ingeniero llamado Isaac lo implementó y desplegó durante un fin de semana

• Hubo debate sobre el uso excesivo de Redis

  • Redis es genial, pero al usarlo hay latencia de red y sobrecarga por serialización
  • Si los datos ya están particionados, un hash map común puede ser mejor
  • En Java existen ConcurrentHashMap, Guava Caches y Caffeine Caches
  • Implementar caché local casi siempre es más rápido que usar la red
  • Redis tiende a usarse en exceso

• La cultura de uso de Redis no ha evolucionado tanto como su popularidad

  • Redis soporta varias estructuras de datos, y a medida que evoluciona la cultura de una empresa se pueden aprender más patrones
  • Es una pena que no exista un compendio de patrones de Redis

• No es un problema de Redis vs. no Redis, sino de trabajar con datos que no se serializan bien

  • Para contadores, feeds de noticias y mensajes de chat, Redis puede ser más eficiente
  • En la mayoría de los casos, MySQL también es suficiente

• El desarrollo de software a menudo tiende a repetir la forma de hacer las cosas de otros

  • Empezó con Memcached y evolucionó hacia Redis
  • Existe la tendencia a usar caché para evitar la complejidad de las bases de datos
  • Las bases de datos siguen siendo complejas y difíciles

• Redis es el único "servidor de estructuras de datos" listo para producción

  • Es útil cuando varias instancias necesitan acceder al mismo servicio

• Puede que no necesites caché

  • Hay experiencias de enfocarse en mejorar la arquitectura sin introducir caché

• La API de Redis es excelente, pero hay riesgos operativos

  • Es bueno como caché, pero no es confiable como almacén de datos de producción

• Sorprende la tendencia a no recomendar el uso de Redis

  • Redis sigue ofreciendo excelentes estructuras de datos y rendimiento

• Redis está bien como caché temporal, pero se queda corto para transacciones o como almacenamiento distribuido

  • Hace falta aprender sobre los problemas de los bloqueos distribuidos