Las bases clave-valor como Redis o DynamoDB, ¿para qué sirven realmente más allá del caché?

#El modelo es más simple que una base de datos, y ese es el punto

Una base de datos clave-valor te da exactamente una operación primaria: dada una clave, obtener (o fijar) su valor, en tiempo aproximadamente constante. No hay planificador de consultas, normalmente no hay joins, y casi nunca un WHERE arbitrario sobre campos cualesquiera. Ese minimalismo es lo que hace que Redis y DynamoDB sean rápidos y escalen horizontalmente, y también es la razón por la que "usa Redis para todo" es la lección equivocada de sacar de lo útiles que son. La lección correcta es más estrecha: son extremadamente buenos para una familia específica de problemas, y el caché es solo el miembro más famoso de esa familia.

#Más allá del caché: para qué sirven realmente las bases clave-valor

Almacenamiento de sesiones. Un token de sesión como clave, un blob pequeño (o un hash) con los datos de la sesión como valor, un TTL para que expire solo: esto es casi el caso de uso perfecto para clave-valor — búsquedas puntuales por un ID aleatorio, de vida corta y alto volumen.

Limitación de tasa y contadores. El incremento atómico (INCR en Redis) es O(1) y seguro bajo concurrencia sin que tu aplicación necesite tomar un lock. Combínalo con EXPIRE y tienes un limitador de ventana fija en tres líneas; las variantes de ventana deslizante usan sorted sets indexados por marca de tiempo en su lugar.

import time
import redis

r = redis.Redis()

def esta_permitido(user_id: str, limite: int = 100, ventana_segundos: int = 60) -> bool:
    ventana = int(time.time()) // ventana_segundos
    clave = f"ratelimit:{user_id}:{ventana}"
    actual = r.incr(clave)
    if actual == 1:
        r.expire(clave, ventana_segundos)
    return actual <= limite

Tablas de clasificación y ranking. El sorted set (ZSET) de Redis mantiene los miembros ordenados por puntaje con inserciones y consultas de rango en O(log N) — "top 10" o "el puesto de este jugador" son operaciones baratas que en una base relacional significarían un escaneo con ORDER BY y una función de ventana.

ZADD leaderboard:semanal 15420 "jugador:8831"
ZADD leaderboard:semanal 18930 "jugador:1027"
ZREVRANGE leaderboard:semanal 0 9 WITHSCORES
ZREVRANK leaderboard:semanal "jugador:8831"

Coordinación distribuida, con cuidado. SET clave valor NX EX 30 adquiere un lock solo si nadie lo tiene, con un tiempo de vida para que un proceso caído no deje el lock trabado para siempre. Esto es genuinamente útil para coordinación del tipo "solo un worker debe procesar este trabajo", aunque los locks de una sola instancia de Redis no son linealizables ante un failover: trátalos como un mutex de mejor esfuerzo, no como una garantía de correctitud para lógica que mueve dinero.

SET pedido:4471:lock "worker-7" NX EX 30

Claves de idempotencia. Guardar "¿ya procesé la solicitud X?" como una clave con un TTL corto es exactamente la forma de búsqueda-puntual-con-expiración para la que se construyó una base clave-valor, y así es como la mayoría de las APIs de pago implementan reintentos idempotentes.

Pub/sub y mensajería efímera. PUBLISH/SUBSCRIBE de Redis da difusión de tipo disparar-y-olvidar para cosas como dashboards en vivo o presencia — no es una cola durable, pero muchas veces es exactamente suficiente para "avisar a quien esté escuchando ahora mismo".

OLTP a gran escala con el diseño de tabla única de DynamoDB. Este es el que sorprende a la gente: DynamoDB es una base clave-valor / de ítems anchos usada como base de datos principal de algunos de los sistemas de mayor tráfico del mundo, diseñando primero los patrones de acceso y codificando cada relación en una clave de partición compuesta más una clave de ordenamiento, en vez de modelar entidades y normalizar.

#Las concesiones que estás aceptando

#DynamoDB: modelar patrones de acceso en vez de entidades

El patrón de tabla única usa una sola tabla física donde la clave de partición (PK) y la clave de ordenamiento (SK) se hacen significar cosas distintas para distintos tipos de ítem, permitiendo responder varias "consultas" con la misma estructura de clave primaria:

Ajustar líneas largas
import boto3

tabla = boto3.resource("dynamodb").Table("AppData")

# Una sola tabla física, varios tipos de entidad lógica, distinguidos por la forma de la clave:
#   PK = "USER#123"   SK = "PROFILE"                -> el perfil del usuario
#   PK = "USER#123"   SK = "ORDER#2026-06-02#4471"   -> uno de los pedidos de ese usuario

tabla.put_item(Item={
    "PK": "USER#123",
    "SK": "ORDER#2026-06-02#4471",
    "orderId": "4471",
    "totalCents": 8900,
    "status": "fulfilled",
})

# "Todos los pedidos del usuario 123, del más reciente al más antiguo" -> una sola Query, sin escanear la tabla:
respuesta = tabla.query(
    KeyConditionExpression="PK = :pk AND begins_with(SK, :prefix)",
    ExpressionAttributeValues={":pk": "USER#123", ":prefix": "ORDER#"},
    ScanIndexForward=False,
)

Esa consulta solo funciona porque el patrón de acceso —"pedidos de un usuario, del más nuevo al más viejo"— se decidió antes de diseñar la tabla. Si más adelante agregas un patrón de acceso nuevo ("todos los pedidos con cierto estado, de todos los usuarios"), probablemente necesites un índice secundario global proyectado de antemano, no una consulta improvisada. Ese costo de modelado anticipado es el precio real de la escalabilidad de DynamoDB, y es el orden de operaciones inverso al de un esquema relacional, donde primero modelas entidades y dejas que el planificador de consultas resuelva después cómo responder lo que sea que preguntes.