Redis = Remote Dictionary Server
Una base de datos en memoria que funciona como caché,
cola de mensajes, broker de pub/sub, y mucho más.
Es increíblemente rápida porque todo vive en RAM.
El más básico. Guarda texto, números, JSON...
Lista ordenada. Perfecta para colas.
Colección sin duplicados.
Como un objeto/diccionario.
Set ordenado por puntuación.
Un caché guarda resultados de operaciones costosas para no repetirlas. Redis es perfecto para esto.
1. Redis GET "api:users:123" 2. IF existe → Devolver resultado 3. IF no existe: - HTTP Request a API - Redis SET "api:users:123" resultado EX 3600 - Devolver resultado
TTL = Time To Live. Redis puede eliminar datos automáticamente después de un tiempo. Perfecto para caché, sesiones, tokens temporales.
// Guardar con expiración de 1 hora (3600 segundos) SET session:abc123 "user_data" EX 3600 // O usar EXPIRE después SET mykey "value" EXPIRE mykey 3600 // Ver cuánto tiempo le queda TTL mykey → 3542 (segundos restantes) // Eliminar expiración (hacer permanente) PERSIST mykey
• Siempre pon TTL en datos de caché para evitar datos stale
• Usa TTL cortos para datos sensibles (tokens, OTPs)
• Redis elimina keys expiradas de forma "lazy" + periódica
Las listas de Redis funcionan como colas perfectas. LPUSH para agregar, RPOP para sacar. First In, First Out.
// Productor: agregar tareas
LPUSH tasks '{"type":"email","to":"user@example.com"}'
LPUSH tasks '{"type":"sms","to":"+123456789"}'
// Consumidor: sacar y procesar
RPOP tasks → '{"type":"email","to":"user@example.com"}'
// Ver cuántas tareas hay pendientes
LLEN tasks → 1
// Bloquear hasta que haya tarea (mejor para workers)
BRPOP tasks 30 → espera hasta 30 segundos
Rate limiting limita cuántas veces se puede hacer algo en un período de tiempo. Redis es perfecto porque es atómico y rápido.
// Key: rate:user_id:minuto_actual
key = "rate:user123:202401211530"
// Incrementar contador
count = INCR key
// Si es el primer request, poner TTL de 60 segundos
IF count == 1:
EXPIRE key 60
// Verificar límite
IF count > 5:
return "Rate limit exceeded"
ELSE:
return "OK, procesar request"
1. Webhook recibe request
2. Code Node: genera key "rate:{{ip}}:{{minuto}}"
3. Redis INCR key
4. Redis EXPIRE key 60 (si count = 1)
5. IF count > 100 → Responder 429 Too Many Requests
6. ELSE → Continuar flujo normal
• Proteger APIs de abuso
• Limitar logins fallidos (seguridad)
• Controlar envío de emails (evitar spam)
• Throttling de webhooks entrantes
Las sesiones guardan información del usuario entre requests. Redis es ideal porque es rápido y permite sesiones compartidas entre servidores.
// Crear sesión
HSET session:abc123 user_id "1" name "Juan" role "admin"
EXPIRE session:abc123 86400 // 24 horas
// Leer sesión
HGETALL session:abc123
→ {"user_id": "1", "name": "Juan", "role": "admin"}
// Actualizar sesión (extender TTL en cada request)
EXPIRE session:abc123 86400
// Cerrar sesión (logout)
DEL session:abc123
Pub/Sub = Publish/Subscribe. Un patrón donde los publicadores envían mensajes a canales y los suscriptores los reciben en tiempo real.
// Suscriptor (en una conexión)
SUBSCRIBE notifications
// Espera mensajes...
// Publicador (en otra conexión)
PUBLISH notifications '{"type":"alert","message":"Nuevo pedido!"}'
// → El suscriptor recibe el mensaje instantáneamente
// Suscribirse a múltiples canales
PSUBSCRIBE notifications:*
// Recibe de notifications:email, notifications:sms, etc.
Los mensajes NO se guardan. Si un suscriptor está desconectado, pierde los mensajes. Para garantía de entrega, usa Redis Streams o colas.
Streams son como Pub/Sub pero los mensajes se guardan. Puedes leer el historial, tener grupos de consumidores, y garantizar entrega.
// Agregar mensaje al stream XADD mystream * user "Juan" action "login" → "1234567890-0" (ID único generado) // Leer últimos mensajes XREAD COUNT 10 STREAMS mystream 0 // Devuelve los últimos 10 mensajes // Leer solo mensajes nuevos (blocking) XREAD BLOCK 5000 STREAMS mystream $ // Espera hasta 5 segundos por nuevos mensajes // Consumer Groups (procesamiento distribuido) XGROUP CREATE mystream mygroup $ MKSTREAM XREADGROUP GROUP mygroup consumer1 COUNT 1 STREAMS mystream >
| Característica | Pub/Sub | Lists | Streams |
|---|---|---|---|
| Persistencia | ❌ | ✅ | ✅ |
| Múltiples consumidores | ✅ | ❌ | ✅ |
| Consumer Groups | ❌ | ❌ | ✅ |
| Historial | ❌ | ✅ | ✅ |
• Event sourcing y logs de eventos
• Procesamiento distribuido con múltiples workers
• Cuando necesitas garantía de entrega
• Cuando necesitas poder "rebobinar" y reprocesar
n8n tiene un nodo nativo para Redis con las operaciones más comunes.
Host: localhost (o tu servidor Redis) Port: 6379 Password: (si tiene) Database: 0 (default) // Si usas Redis en la nube: Host: redis-12345.cloud.redislabs.com Port: 12345 Password: tu_password_secreto SSL: true
💡 Pro Tip: Para comandos avanzados no soportados
por el nodo Redis, usa el nodo Code con una librería como ioredis.
Tu flujo llama a una API externa 1000 veces/día. La API es lenta (500ms) y tiene límite de 100 requests/hora. Necesitas cachear las respuestas.
// Genera una key única por recurso cache:product:12345 cache:user:abc123 cache:api:weather:madrid // TTL según frecuencia de cambio Productos: 1 hora (3600s) Usuarios: 5 minutos (300s) Clima: 10 minutos (600s)
Tu webhook recibe requests externos. Quieres limitar a 100 requests por minuto por IP para evitar abuso.
const ip = $input.first().headers['x-forwarded-for'] || 'unknown';
const minute = Math.floor(Date.now() / 60000);
const key = `rate:${ip}:${minute}`;
return [{
json: {
key: key,
ip: ip
}
}];
💡 Pro Tip: Para rate limiting más sofisticado (sliding window, token bucket), considera usar Redis + Lua scripts o una librería especializada.
Recibes muchos webhooks de pagos. Procesarlos toma tiempo (enviar email, actualizar DB, llamar APIs). Necesitas responder rápido y procesar después.
• Webhook responde en <100ms (Stripe happy)
• No pierdes eventos si hay pico de tráfico
• Puedes escalar consumidores independientemente
• Fácil de monitorear (LLEN para ver cola)
• Usar KEYS * en producción (bloquea Redis)
• No poner TTL y llenar la memoria
• Guardar objetos muy grandes
• No manejar desconexiones de Redis