Qué es Redis realmente
Redis es un almacén clave-valor que vive en memoria. Le das una clave ("user:1042:profile") y un valor, y te devuelve el valor cuando lo pides — normalmente en mucho menos de un milisegundo, porque nada toca un disco en el camino de lectura. Además de cadenas simples trae estructuras de datos prácticas: hashes para objetos, listas y conjuntos ordenados para feeds y rankings, conjuntos para comprobaciones de pertenencia, contadores con incrementos atómicos.
Esa combinación — velocidad de RAM más estructuras de datos de verdad — es la razón por la que aparece en casi cualquier stack web serio. No compite con tu base de datos en ser duradero y consultable; compite con tu base de datos en *responder rápido la misma pregunta repetida*, y ese concurso lo gana por dos o tres órdenes de magnitud.
El problema que resuelve: trabajo costoso repetido
Mira lo que hace un backend típico por petición: cargar el usuario, cargar la configuración, ejecutar la misma consulta del listado de productos o del menú que no ha cambiado desde el visitante anterior, renderizarlo todo. La mayor parte de ese trabajo produce la misma respuesta que producía hace unos segundos. La base de datos, obediente, lo re-ejecuta de todas formas — parsear, planificar, leer páginas, hacer joins — y bajo tráfico esas consultas repetidas se convierten en el cuello de botella mucho antes que la CPU.
El patrón cache-aside arregla exactamente esto: consulta primero Redis; si hay acierto, devuelve la copia cacheada; si hay fallo, ejecuta la consulta real, guarda el resultado con un tiempo de vida y devuélvelo. Una página que necesitaba quince consultas ahora necesita quince lecturas de memoria en el camino caliente. La base de datos pasa de recibir cada petición a recibir una por ventana de TTL — que es también la razón por la que los sitios con Redis sobreviven picos de tráfico que sin él los habrían tumbado.
Las sesiones son el segundo trabajo clásico. Guardar las sesiones de login en Redis en lugar de en el disco local significa que cualquier réplica de tu app puede atender a cualquier usuario — que es precisamente lo que hace posible el escalado horizontal.
Dónde Redis no va a ayudar
Una frontera honesta te ahorra semanas. Redis no hace rápida una consulta lenta la primera vez — solo abarata la *segunda* ejecución, así que un índice que falta en la base de datos sigue siendo un índice que falta. No arregla una ruta de red lenta hasta el origen ni imágenes pesadas; esos son problemas de entrega, que se resuelven en el edge, no en RAM. Y no es un sistema de registro duradero: la memoria es finita y las expulsiones son por diseño, así que todo lo que no puedas permitirte perder pertenece a la base de datos, con Redis guardando una copia desechable.
El coste real de cachear es la invalidación: un precio obsoleto o una comprobación de permisos desactualizada es un bug que tus usuarios ven. Mantén TTLs cortos donde la corrección importa, borra claves explícitamente cuando cambien los datos subyacentes, y resiste la tentación de cachear cosas que cambian en cada petición — una caché con una tasa de aciertos cercana a cero es puro sobrecoste.
Redis gestionado: la vía del add-on
Operar Redis tú mismo no es difícil el día uno — es difícil el día doscientos: límites de memoria, reinicios, actualizaciones de versión, asegurarte de que la app se reconecta. Una instancia gestionada pliega todo eso dentro de la plataforma.
En la plataforma de contenedores de cdn.com.tr, Redis es un add-on que adjuntas a una app. Activarlo aprovisiona la instancia e inyecta la conexión en el entorno de tu app automáticamente — REDIS_HOST, REDIS_PORT, REDIS_DB y una REDIS_URL lista para usar — de modo que frameworks como Laravel, Django o WordPress lo recogen con configuración, no con código. La plataforma WordPress usa el mismo add-on como caché de objetos, que es uno de los cambios individuales de mayor palanca para un sitio WordPress con tráfico. Desactiva el add-on y las variables se limpian con él.
Activa Redis gestionado en una app con cdnctl
# attach a managed Redis instance to your app
cdnctl container addons enable-redis --account <uuid> --app <app_uuid> --env-prefix REDIS
# see what is attached
cdnctl container addons list --account <uuid> --app <app_uuid>
# remove it again
cdnctl container addons disable-redis --account <uuid> --app <app_uuid>Redis y la CDN: dos capas de caché, trabajos distintos
Merece la pena ser preciso sobre cómo se relaciona una caché en memoria con una CDN, porque ambas son "caché" y no son intercambiables. La CDN cachea *respuestas* — HTML terminado, imágenes, archivos — cerca del visitante, de modo que muchas peticiones ni siquiera llegan a tu aplicación. Redis cachea *datos dentro* de la aplicación, de modo que las peticiones que sí llegan son baratas de servir.
Se potencian mutuamente: el edge absorbe la mayoría cacheable del tráfico, y Redis hace rápido el resto personalizado y no cacheable. Un stack con ambas suele servir las páginas anónimas desde el edge en decenas de milisegundos y las páginas con sesión desde un backend calentado por Redis — que es la arquitectura detrás de la mayoría de los sitios que se sienten instantáneos bajo carga.
Preguntas frecuentes
¿Redis es una base de datos?
Puede persistir a disco, pero ese no es el trabajo para el que deberías contratarlo. Trata a Redis como una copia rápida y desechable de datos cuya fuente de verdad vive en una base de datos de verdad. Si perder los datos doliera, no deberían estar solo en Redis.
¿Qué debería cachear primero?
El log de consultas responde a esto: las consultas costosas más frecuentes cuyos resultados cambian rara vez — listados de productos, menús, configuraciones, fragmentos renderizados. Cachea esas con un TTL sensato y normalmente capturas la mayor parte de la ganancia en una tarde.
¿Cuánta memoria necesita una caché Redis?
Menos de lo que la mayoría asume — los resultados de consultas cacheados y las sesiones son pequeños. Empieza modesto, vigila la tasa de aciertos y las expulsiones, y crece solo cuando aparezcan expulsiones de claves todavía útiles. Una tasa de aciertos alta en una instancia pequeña vale más que una enorme y ociosa.
¿WordPress se beneficia de Redis?
Notablemente. WordPress relee opciones y objetos de MySQL constantemente; una caché de objetos con Redis convierte eso en lecturas de memoria. En la plataforma WordPress gestionada el mismo add-on de Redis sirve como caché de objetos, combinado con la caché del edge por delante.