Redis no es solo un almacén clave-valor: ¿qué estructuras de datos ofrece y qué problemas reales resuelve?

#Redis como servidor de estructuras de datos, no un mapa hash con puerto de red

El modelo mental de "Redis es solo un almacén clave-valor rápido" es el que más rápido se cae en una entrevista senior. El valor detrás de cualquier clave puede ser un string, pero con la misma facilidad puede ser un hash, un sorted set, una lista, un set, un stream, un bitmap o un HyperLogLog, cada uno con su propia familia de comandos y sus propias garantías de complejidad, y cada uno existe porque resuelve una clase específica de problema que un simple GET/SET no puede resolver sin traer todo el blob a tu aplicación y hacer el trabajo ahí.

#Hashes: un registro, no un blob

Un valor String te obliga a serializar un objeto completo para actualizar un solo campo. Un Hash guarda pares campo-valor bajo una sola clave, así que un campo individual se puede leer o escribir en O(1) sin tocar el resto.

HSET cart:user:42 sku:1001 2 sku:2002 1
HGET cart:user:42 sku:1001
HINCRBY cart:user:42 sku:1001 1
HGETALL cart:user:42

Un carrito de compras, una sesión de usuario o un registro de producto encajan naturalmente en un hash: incrementar la cantidad de un SKU (HINCRBY) nunca requiere leer y reescribir todo el carrito como JSON. Compáralo con un valor de tipo string en JSON, donde la misma actualización significa GET, deserializar, mutar un campo, serializar, SET; y una carrera entre dos actualizaciones concurrentes puede descartar silenciosamente una de ellas.

#Sorted sets: el orden como característica de primera clase

Un Sorted Set (ZSET) guarda miembros únicos, cada uno con un score de punto flotante, mantenidos internamente en orden por score (una skip list más una tabla hash), así que las consultas por rango, ya sea por posición o por score, son baratas.

Tabla de posiciones (leaderboard), el uso canónico:

ZADD leaderboard:season1 4500 "player:17"
ZADD leaderboard:season1 6200 "player:42"
ZINCRBY leaderboard:season1 150 "player:17"
ZREVRANGE leaderboard:season1 0 9 WITHSCORES
ZREVRANK leaderboard:season1 "player:17"

El rate limiting de ventana deslizante es el otro uso estrella, y vale la pena saberlo de memoria: usa la marca de tiempo actual como score, el id de la petición como miembro, recorta todo lo más viejo que la ventana, y luego cuenta lo que queda.

ZADD ratelimit:user:42 1735142400123 "req-a1b2"
ZREMRANGEBYSCORE ratelimit:user:42 -inf (1735142400123-60000)
ZCARD ratelimit:user:42

Si ZCARD retorna más del número de peticiones permitidas, rechaza la petición. Esto te da una ventana deslizante exacta (no la aproximación en cubos de un contador de ventana fija) en tres comandos, todos O(log N). ZADD, ZINCRBY, ZRANGE/ZREVRANGE y ZREMRANGEBYSCORE son todos O(log N) (u O(log N + M) para un rango de M resultados): suficientemente baratos como para correr en cada petición.

#Listas: una cola, hasta que deja de alcanzar

Una List es, por dentro, una lista doblemente enlazada: O(1) para insertar y sacar en cualquiera de los dos extremos, O(N) para acceder al medio. Eso la vuelve una cola de trabajos mínima y natural:

LPUSH jobs:emails '{"to":"a@x.com","template":"welcome"}'
BRPOP jobs:emails 5

Esto funciona, y así es genuinamente como arrancan muchos sistemas de trabajos en segundo plano livianos. Su límite es la durabilidad: BRPOP elimina el elemento en el instante en que un worker lo recoge. Si ese worker se cae a mitad del trabajo, el trabajo simplemente desaparece: nunca hubo un paso de confirmación, porque una List no tiene el concepto de "en curso pero aún no confirmado como terminado".

#Streams: una lista que recuerda quién ya leyó qué

Un Stream es un log de solo-anexar (append-only), algo así como una partición liviana de Kafka viviendo dentro de Redis, donde las entradas nunca se eliminan al leerlas, y varios consumer groups pueden llevar cada uno su propia posición de forma independiente, con confirmación explícita.

XADD orders:events '*' orderId 9931 status "created"
XREADGROUP GROUP shipping consumer-1 COUNT 10 STREAMS orders:events '>'
XACK orders:events shipping 1735142400123-0
XPENDING orders:events shipping

XADD anexa (el '*' le pide a Redis que genere automáticamente un id basado en timestamp); XREADGROUP le entrega a un consumer group las siguientes entradas no leídas; XACK marca una como terminada. Fundamentalmente, una entrada que fue entregada pero nunca confirmada permanece visible en la lista de entradas pendientes del grupo (XPENDING), así que los trabajos en vuelo de un worker caído no se pierden: simplemente esperan a que otro consumidor los reclame (XCLAIM). Esa es la garantía de durabilidad que una cola basada en List nunca tuvo.

#Eligiendo la estructura

🧠 Check your understanding
0/4 · 0/4 answered
1. Necesitas un rate limiter de ventana deslizante exacto (no una aproximación de ventana fija). ¿Qué estructura y enfoque de Redis encaja mejor?
Un String con INCR y un TTL fijoUn Set con SADD y SCARDUn Sorted Set, dando a cada petición un score de timestamp y recortando con ZREMRANGEBYSCOREUna List con LPUSH/LTRIM
2. Un worker que usa BRPOP sobre una List de Redis se cae justo después de sacar un trabajo pero antes de terminarlo. ¿Qué pasa con ese trabajo?
Se vuelve a encolar automáticamente tras un timeoutSe mueve a una lista de mensajes muertos (dead-letter)Redis lo reintenta 3 veces por defectoSe pierde: las Lists no tienen concepto de confirmación ni de entradas pendientes
3. ¿Qué le da un consumer group de un Stream que una cola basada en List simple no ofrece?
Seguimiento de posición por consumidor más una lista de entradas pendientes para reclamar trabajo no entregadoCompresión automática de datosMenor latencia promedioCifrado incorporado de los mensajes
4. ¿Por qué es riesgoso ejecutar KEYS * contra un keyspace grande en producción?
Requiere privilegios de administradorSolo funciona con Sorted SetsElimina permanentemente las claves encontradasRedis es de un solo hilo para procesar comandos, así que un KEYS lento bloquea a todos los demás clientes hasta terminar