Redis ayuda cuando mantener en RAM datos reutilizados, sessions o resultados calculados evita trabajo costoso en database o application. Instalar Redis por sí solo no crea rendimiento: necesitas un workload cacheable, invalidación correcta y una política de memoria.
Mito: Redis elimina el bottleneck de la base de datos
Realidad: solo ayudan los cache hits. Las queries únicas o transaccionales siguen llegando a la DB. Primero identifica la operación cara.
Consulta la guía de memory planning de bases de datos y la optimización de WordPress.
Cuatro usos habituales de Redis
| Use case | Beneficio | Riesgo |
|---|---|---|
| Object cache | reutilizar resultados | stale data |
| Session store | sessions compartidas | availability |
| Queue/state | coordinación rápida | persistence semantics |
| Rate limits | contadores atómicos | errores de TTL/policy |
maxmemory y eviction son parte de la operación
Define un límite de memoria y qué ocurrirá al alcanzarlo. Con `noeviction`, las writes pueden empezar a fallar. Replication y persistence también necesitan memoria para buffers.
Cache invalidation es el verdadero trabajo de ingeniería
- qué key se crea;
- qué TTL tiene;
- qué evento invalida el cache;
- qué ocurre en cache miss;
- qué pasa tras restart de Redis.
Cuándo no añadiría Redis todavía
- el bottleneck no está medido;
- el VPS ya tiene memory pressure;
- el workload se repite poco;
- no existe una invalidation model segura.
Para control total, VPS no administrado es natural. En modelo gestionado, confirma Redis dentro del scope de Managed VPS. Para PHP, revisa la guía de PHP-FPM tuning.
Redis es una herramienta para un problema concreto de latency/capacity, no un acelerador universal.
