Redis mantiene en memoria los datos de alta rotación y baja criticidad —carrito de compra, sesiones y la cola de tareas—, con latencias de microsegundos. No requiere persistencia garantizada: la fuente de verdad reside en PostgreSQL.
¿Qué es?
Redis es un almacén de pares clave-valor en memoria. Opera íntegramente en RAM, lo que le confiere latencias de microsegundos, idóneo para estados efímeros. Ante una caída se pierde ese estado temporal, pero la operación continúa, ya que la información persistente reside en PostgreSQL.
Funciones principales
Carrito de compra: HSET cart:{cliente_id} producto_id cantidad. Lectura instantánea mientras el cliente navega.
Sesiones: SETEX session:{token} 3600 {usuario_id}. Expiración automática a la hora.
Cola de tareas: LPUSH tasks {task_json}. Celery consume de esta cola para emitir comprobantes y enviar notificaciones.
Caché de catálogo: SET producto:{id} {json} EX 1800. Durante 30 minutos se reutiliza sin consultar PostgreSQL.
Limitación de tasa: INCR request_count:{ip}. Recuento de peticiones por IP para mitigar el abuso automatizado.
Bloqueos distribuidos: SET lock:{recurso} "acquired" NX EX 10. Previene condiciones de carrera en operaciones concurrentes.
Limitaciones y restricciones
Capacidad en RAM: Todo el conjunto reside en memoria; si excede la RAM disponible, el servicio se degrada o falla.
Volatilidad: Sin persistencia garantizada; ante una caída se pierde el estado en memoria (mitigable con snapshots o AOF).
Transaccionalidad limitada: No ofrece garantías ACID completas ni rollback condicional como PostgreSQL.
Retraso de replicación: Si una réplica no recibe el cambio antes de una caída del primario, puede perder datos.
Expiración de claves: Omitir el TTL (EX) deja las claves de forma indefinida; exige disciplina en el código.
Propósito del componente
Almacenar estado temporal con latencia mínima, aliviar la carga de PostgreSQL (las consultas en memoria son órdenes de magnitud más rápidas), absorber picos de tráfico sin degradar el servicio y habilitar el procesamiento asíncrono mediante colas de tareas.
Por qué: Redis es el estándar de facto para caché. django-redis se integra de forma transparente con Django. Celery es el estándar para tareas asíncronas. Redis Sentinel aporta alta disponibilidad y Redis Cluster habilita el escalado horizontal cuando el volumen supera la RAM de un nodo.
Información técnica adicional
Persistencia: AOF (append-only file) registra cada operación; RDB (snapshots) vuelca el estado completo. Configurable según la tolerancia a pérdida.
Replicación: Esquema primario-réplica; las lecturas se reparten entre réplicas y las escrituras van al primario y se propagan.
Políticas de evicción: Al llenarse la memoria, Redis descarta claves según la política configurada (LRU, LFU, aleatoria).
Pipelining: Agrupa múltiples comandos en una sola petición, reduciendo la latencia de red de forma notable.
Pub/Sub: Suscripción a canales para notificaciones en tiempo real; adecuado para WebSockets.
Métricas importantes
Uso de memoria: Alertar al superar el 80% de la capacidad; acción: ampliar RAM o ajustar la evicción.
Evicciones: Un valor mayor que cero indica memoria saturada forzando descartes; acción: ampliar RAM.
Latencia: P99 < 1 ms. Por encima de 10 ms, indica sobrecarga.
Retraso de replicación: El offset debe permanecer sincronizado; un retraso sostenido pone datos en riesgo.
Tasa de aciertos: Porcentaje de peticiones servidas desde Redis; objetivo superior al 80%.
Redis es determinante para el rendimiento, pero no es un almacén permanente: la información crítica debe residir siempre en PostgreSQL. Tratado como caché, su pérdida supone un inconveniente temporal, no una contingencia grave.