Redis es rápido. El desafío es que es un caché: si los datos no coinciden con la base de datos, tienes una bomba de tiempo.
Patrones de caché: cache-aside vs write-through
Cache-aside (Lazy Loading): lee de caché si existe, sino de BD y cachea. Simple, pero riesgo de caché vacío al inicio.
Write-through: al escribir, actualiza BD y caché juntos. Más seguro, pero requiere coordinación.
- Cache-aside: simple para reads.
- Write-through: seguridad, algo más complejo.
- Combina ambos según el caso.
Invalidación: cuando cachea se vuelve stale
El problema central es: cuando actualizo un registro en BD, el caché puede quedar viejo. Las estrategias son: TTL (expira después de X tiempo), invalidación explícita (borra cuando escribo), o monitoreo de cambios.
Ninguna es perfecta. Elige según qué tolerancia de staleness tienes.
- TTL: simple, automatiza expiración.
- Invalidación explícita: control total.
- Change Data Capture: complejo, pero preciso.
Keys y nombrado consistente
Los keys deben seguir convención clara. usuario:123, posts:user:456. Eso facilita invalidar grupos de keys sin tocarlas individualmente.
El caos viene cuando los keys se generan de forma inconsistente en múltiples sitios.
- Convención de nombres: recurso:identificador
- Centraliza generación de keys.
- Documenta qué datos cachea cada key.
Caché distribuido: cuando es un Redis y crece
Redis soporta replicación y clustering para alta disponibilidad. Lo importante es que cache no sea punto único de fallo: si Redis cae, la aplicación tiene plan B.
La mayoría de setups reales usan Redis con persistencia y replicación.
Un caché que se cae y causa outage de aplicación es peor que no tener caché. Requiere arquitectura que tolera fallo de caché.
Monitoreo de hit rate
El hit rate (qué % de requests encuentran valor en caché) determina si el caché ayuda o no. Si es bajo, quizá estés cacheando lo equivocado.
Las herramientas de Redis muestran hit rate, memory usage y operaciones por segundo. Monitoréalos regularmente.