Qué construimos con él
Redis guarda los datos que un servicio necesita de inmediato y podría regenerar si los perdiera. Resultados de consultas cacheados que si no golpearían la base de datos en cada petición, estado de sesión, contadores de límite de tasa, bloqueos de vida corta y las colas de trabajos que sacan el trabajo lento de la ruta de la petición.
Esto último suele ser la mayor victoria en un producto. Enviar un correo, generar un documento o llamar a una API de terceros no pertenece dentro de la petición HTTP que un usuario está esperando: empujarlo a una cola es lo que mantiene una página con respuesta cuando un servicio aguas abajo está teniendo un mal día.
Dónde encaja
Delante de PostgreSQL, no en su lugar. El patrón que usamos es aburrido a propósito: la base de datos relacional es dueña de la verdad, Redis es dueño de aquello que merece no recalcular, y cada clave tiene una caducidad para que una caché obsoleta sea un problema temporal y no permanente.
Cuándo lo recomendamos
Cuando una consulta concreta está medidamente caliente, cuando necesitas trabajos en segundo plano, o cuando el estado tiene que compartirse entre varias instancias de un servicio.
No como primer movimiento. Añadir una caché antes de saber qué es lento te compra un segundo sistema que operar y una nueva clase de bug: datos correctos en un sitio y equivocados en otro. Mide primero y cachea después aquello a lo que apunta el perfilado.
