Cargas de trabajo de cache y queue de Redis en Dockup

Las cargas de trabajo de cache y queue de Redis pueden usar el mismo servicio de Redis gestionado, pero tienen requisitos de corrección diferentes. Normalmente, una cache se puede reconstruir después de una pérdida. Una queue puede representar trabajo que no debe descartarse silenciosamente ni procesarse dos veces.

Dockup aprovisiona Redis como una base de datos gestionada, proporciona operaciones de consulta de tamaño y logs, admite flujos de backup y migración de nodos, y puede conectar la base de datos con los servicios de la aplicación mediante la red privada del proyecto.

¿Cómo se aprovisiona Redis gestionado?

Crea Redis en el workspace seleccionado:

dockup db create \
  --name app-redis \
  --type redis \
  --json

Confirma el destino de la base de datos:

dockup db list --json

Guarda los datos de conexión devueltos fuera del control de versiones y asígnalos al servicio consumidor como un secret:

dockup env set REDIS_URL="$REDIS_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

El redeploy crea un contenedor nuevo de la aplicación con el entorno actualizado. Reiniciar el contenedor antiguo no aplica un valor deseado almacenado recientemente.

Usa bases de datos o instancias de Redis independientes cuando el comportamiento de eviction de la cache y la retención de una queue crítica no deban competir por la misma memoria. El aislamiento también simplifica el diagnóstico de incidentes y el control de acceso.

¿Cuándo debe usarse Redis como cache?

Una cache reduce el trabajo repetido o la latencia al almacenar datos derivados. La fuente de verdad permanece en otro lugar, normalmente PostgreSQL, MySQL, MongoDB, una API externa o un cálculo determinista.

Un diseño sólido de cache define:

• Formato y namespace de las cache keys.
• Tiempo de vida.
• Nivel máximo de obsolescencia aceptable.
• Disparador de invalidación.
• Comportamiento ante un miss.
• Comportamiento cuando Redis no está disponible.
• Protección frente a una thundering herd.
• Qué datos no deben almacenarse nunca en cache.

Fallo	Comportamiento seguro de la cache
Falta la key	Recalcular o leer de la fuente de verdad
Redis no está disponible	Degradar a la fuente con protección de rate
Entrada obsoleta	Expirar o invalidar
Cambio de serialización	Versionar el namespace de keys
Presión de memoria	Evictar primero los datos que se puedan reconstruir
Hot key	Añadir cache local, sharding o request coalescing

No hagas que toda la aplicación deje de estar disponible únicamente porque una cache opcional esté caída. Usa timeouts acotados y rutas de fallback. Sin embargo, tampoco ocultes todos los fallos: una caída prolongada de la cache puede sobrecargar la base de datos de origen.

¿Qué cambia cuando Redis se usa como job queue?

Una queue representa trabajo pendiente, por lo que la aplicación debe definir la semántica de entrega y recuperación. Redis es un servidor de estructuras de datos; las garantías dependen de la librería de queue y del protocolo de los workers.

Decide:

1. ¿Cuándo se considera aceptado un job?
2. ¿Cuándo se confirma?
3. ¿Qué ocurre si un worker falla después de ejecutar el efecto secundario, pero antes de confirmar?
4. ¿Cómo se retrasan y limitan los retries?
5. ¿Dónde terminan los jobs que fallan permanentemente?
6. ¿Cómo se hace segura la ejecución duplicada?
7. ¿Cómo se observa la profundidad de la queue?
8. ¿Se puede reconstruir el payload del job?

Construye workers idempotentes. Un pago, un email o una importación de datos pueden entregarse más de una vez después de un fallo. Usa una idempotency key de negocio y registra la finalización en la base de datos que actúa como fuente de verdad.

Separa los nombres de las queues por carga de trabajo y prioridad. Un job lento de procesamiento multimedia no debe bloquear el procesamiento de restablecimientos de contraseña o webhooks. Evita incluir secrets en los payloads de los jobs cuando baste con un ID de referencia.

Un despliegue de cache y queue de Redis debe documentar qué keys son desechables y cuáles representan trabajo de negocio.

¿Cómo conecta la red privada los servicios con Redis?

Activa la red del proyecto:

dockup network enable production --json

El servicio de Redis será accesible mediante su hostname estable <slug>.internal desde los servicios del mismo proyecto. Haz un redeploy de la aplicación para que Dockup pueda inyectar las variables de conexión internas.

Para hacer que Redis solo sea privado:

dockup db private production/app-redis --json

Restaura el listener público cuando sea necesario:

dockup db private production/app-redis --off --json

La red privada elimina la ruta a través de Internet público para el tráfico entre servicios del mismo proyecto, pero no sustituye la autenticación. Mantén en secreto los datos de conexión de Redis y restringe qué servicios los reciben.

Los distintos proyectos no pueden acceder a la red privada de los demás. Este límite puede ser útil cuando producción y staging no deben compartir cache keys ni trabajo de queue.

Consulta red privada y dominios internos para conocer el modelo completo.

¿Cómo deben afectar los fallos de Redis a la aplicación?

Clasifica la carga de trabajo antes de escribir el código de recuperación.

Carga de trabajo	Tolerancia a la pérdida	Respuesta ante una caída
Cache de fragmentos HTML	Alta	Reconstruir desde el origen
Almacén de sesiones	Baja a media	Puede cerrar las sesiones de los usuarios; diseña un fallback
Contadores de rate limit	Depende de la política	Fallar open o closed de forma explícita
Job queue	Baja	Dejar de aceptar trabajos o persistirlos en otro lugar
Distributed lock	Muy baja en secciones críticas	Usar fencing/idempotencia
Cache de funcionalidades	Alta	Usar un valor predeterminado o el origen

Un cliente de cache no debería hacer retry eternamente. Los retries prolongados pueden consumir todos los workers de la aplicación y convertir un incidente de Redis en una caída total. Los workers de una queue deben aplicar backoff, mostrar el trabajo fallido y detenerse después de una política definida.

Consulta el tamaño de Redis y los logs de runtime de la aplicación consumidora:

dockup db size production/app-redis --json
dockup logs production/api --json

El crecimiento del tamaño puede indicar que faltan expiraciones, una profundidad de queue descontrolada, payloads demasiado grandes o namespaces abandonados. No trates el reinicio de una base de datos como primera respuesta ante timeouts de la aplicación; comprueba antes la configuración, la red y el comportamiento del cliente.

¿Cómo encajan el backup, la migración y la monitorización de Redis?

Dockup expone el flujo de backup de la base de datos gestionada:

dockup db backups production/app-redis --json
dockup db backup production/app-redis --json

Que un backup de Redis cumpla el objetivo de recuperación de la carga de trabajo depende del significado de los datos. Un backup de cache puede ser innecesario. Un backup de queue todavía puede perder el trabajo aceptado después del punto del backup. Cuando sea posible, los jobs críticos para el negocio deben tener un registro de origen recuperable fuera de la queue.

Mueve Redis entre nodos con:

dockup db migrate production/app-redis \
  --node <nodeId> \
  --json

Planifica el impacto de la migración en los clientes y workers. Confirma que el comportamiento de reconexión, retry e idempotencia funciona antes de pasar a producción.

Supervisa métricas del nivel de la aplicación además del tamaño de la base de datos:

• Ratio de aciertos de la cache.
• Latencia de los miss.
• Evictions.
• Profundidad de la queue y antigüedad del job más antiguo.
• Recuentos de jobs correctos, retries y fallos.
• Concurrencia de los workers.
• Errores de conexión de Redis.
• Tamaño de los payloads.

Dockup mide el consumo de CPU, RAM y disco por minuto en relación con el saldo del plan. El plan Pro recomendado cuesta 20 $ al mes e incluye 20 $ de crédito de uso, pero las métricas de la carga de trabajo —no el nombre del plan— deben guiar las decisiones de capacidad.

¿Cuál es una checklist segura de Redis para producción?

Antes del lanzamiento, verifica:

1. El destino exacto project/db.
2. Las responsabilidades de la cache y la queue están documentadas.
3. La URL de conexión es un secret enmascarado.
4. La política de red privada está decidida.
5. Toda cache tiene TTL o una invalidación explícita.
6. Los workers de la queue son idempotentes.
7. El sistema de queue define el comportamiento de retry y dead letter.
8. Existen alertas para el tamaño y la profundidad de la queue.
9. Se conocen el valor y las limitaciones del backup.
10. El reinicio y la migración requieren aprobación.

Ejemplo de separación de cache y queue

Una aplicación pequeña puede comenzar con una única base de datos de Redis cuando el riesgo sea bajo, pero debe usar prefijos de keys claros:

cache:user-profile:v2:<user-id>
cache:catalog:v5:<product-id>
queue:email:waiting
queue:email:active
lock:invoice:<invoice-id>

A medida que crece la carga de trabajo, separa el estado de la queue crítica del estado de la cache sometida a eviction agresiva. Este es un límite operativo, no solo una preferencia de nomenclatura.

Un diseño correcto de cache y queue de Redis hace que el comportamiento de la aplicación sea predecible cuando Redis está rápido, lento, vacío o no disponible.

Para las operaciones relacionales de fuente de verdad, consulta PostgreSQL gestionado. Para conocer opciones más amplias de capacidad, consulta estrategias de escalado de bases de datos. Usa la referencia de Dockup CLI para consultar los comandos actuales de bases de datos.

Define la evolución de las keys y los payloads

Los datos de cache y queue sobreviven a un único proceso de la aplicación. Una nueva release puede leer keys escritas por la release anterior durante un cutover blue-green. Versiona los namespaces de keys y los payloads de los jobs para que ambas versiones puedan coexistir.

En las queues, incluye una versión del payload y mantén los workers preparados para procesar al menos las versiones que aún puedan estar esperando. Un rollback del despliegue puede restaurar código antiguo mientras los jobs con el formato nuevo permanecen en Redis. Sin compatibilidad, el rollback de la aplicación puede aumentar los fallos.

Prueba deliberadamente la presión sobre los recursos

En un entorno que no sea de producción, prueba keys ausentes, respuestas lentas de Redis, resets de conexión, acumulación de trabajos en la queue, entregas duplicadas y una condición de memoria llena o casi llena. Observa si la aplicación falla open, falla closed, hace retry o sobrecarga otra dependencia.

Un runbook de cache y queue de Redis debe establecer límites para los intentos de retry y la concurrencia. Los bucles de retry ilimitados pueden consumir todos los workers y dificultar la recuperación más que el incidente original.

Mantén una ruta de recuperación desde la fuente de verdad

Para los jobs críticos, almacena suficiente estado en la base de datos principal para reconstruir el trabajo después de perder Redis. Una queue debe acelerar el procesamiento, no convertirse en el único registro de que ocurrió una acción del cliente.

Empieza con un despliegue verificable

Aprovisiona Redis en un proyecto que no sea de producción, prueba el fallback de la cache y la entrega duplicada de jobs, y haz explícita la política de fallos antes de dirigir trabajo crítico al sistema.

Empieza gratis en app.dockup.ai. El plan Free cuesta 0 $ al mes, incluye 10 $ de crédito inicial y admite un workspace, tres bases de datos y tres despliegues.

FAQ

¿Puede Dockup crear Redis gestionado?

Sí. Usa el comando de creación de bases de datos gestionadas con el tipo redis y conecta después la aplicación mediante los datos de conexión devueltos, almacenados como un secret.

¿Deberían compartir una instancia de Redis los datos de la cache y la queue?

Pueden hacerlo en una carga de trabajo pequeña y de bajo riesgo, pero la separación es más segura cuando la eviction de la cache y la retención de una queue crítica tienen requisitos distintos de disponibilidad y memoria.

¿Garantiza Redis que un job encolado se ejecute exactamente una vez?

No debe asumirse una garantía general de ejecución exactamente una vez. La semántica de entrega depende de la librería de queue y del diseño de los workers, por lo que los efectos secundarios deben ser idempotentes.

¿Puede Redis usar la red privada de Dockup?

Sí. Activa la red del proyecto, haz un redeploy de los servicios consumidores para obtener las variables internas y, opcionalmente, configura la base de datos de Redis para que sea solo privada.

¿Es suficiente un backup de Redis para una queue de jobs crítica?

No necesariamente. Representa un punto en el tiempo y puede no incluir el trabajo aceptado más recientemente. Conserva registros de origen recuperables y define la recuperación de jobs en el nivel de la aplicación.