El viernes por la noche, la tienda muestra "pedido confirmado". El correo electrónico de confirmación nunca salió. El lunes por la mañana, el soporte descubrió una tabla de "trabajos" vacía en el lado de la aplicación, pero cientos de entradas en "trabajos_fallidos", todas vinculadas a un tiempo de espera de SMTP después de la actualización de la versión del fin de semana.
Este escenario es banal: la interfaz web responde rápidamente porque Laravel envió correctamente el trabajo, pero nadie monitoreó el consumo ni los fallos. Las colas no son un problema cuando todo va bien. Se vuelven visibles cuando un trabajador se detiene, un controlador mal configurado cambia a "sincronización" o un reintento agresivo amplifica una falla externa.
Controlador, conexión y lo que realmente ejecuta Laravel
Un trabajo de Laravel no es mágico: es un mensaje serializado (clase, carga útil, intentos) almacenado en un backend: Redis, base de datos, SQS, Beanstalkd. El trabajador (queue:work u Horizon) lo abre, crea una instancia de la clase, ejecuta handle() y luego reconoce o marca el error.
| Conductor | Cuando usarlo | Límite frecuente |
|---|---|---|
redis | Producción con múltiples trabajadores, baja latencia | Redis debe ser persistente y monitoreado |
base de datos | Pequeño volumen, sin intermediario | Contención en la tabla de "empleos" de alta carga |
cuadrados | Nube de AWS, desacoplamiento regional | Costo y visibilidad de los DLQ a configurar |
sincronizar | Sólo pruebas locales | Ejecución en línea: sin resiliencia |
En el hosting compartido, Redis administrado o un pequeño VPS dedicado al broker evita mezclar carga web y consumo de trabajo. En un solo VPS, documente quién reinicia al trabajador después de una implementación: un "supervisor" mal recargado permite que la cola crezca sin errores visibles en el lado HTTP.
Un sitio que responde en 200 ms puede estar funcionalmente inactivo si sus trabajadores han estado detenidos desde el día anterior.
Reintentos, retrocesos y trabajos idempotentes
Laravel reintenta automáticamente los trabajos que arrojan una excepción, dependiendo de $tries, $backoff o $retryUntil. Esto es útil para una API de terceros que no está disponible temporalmente. Esto es peligroso para un trabajo que envía dinero, crea una factura o llama a un webhook no idempotente.
Reglas pragmáticas:
- Retroceso exponencial en lugar de diez intentos en diez segundos por el mismo error estructural.
$maxExceptionspara detener un trabajo defectuoso antes de agotar la cola.- Idempotencia: una segunda pasada no debe duplicar el efecto (llave única en la base, bloqueo Redis, estado “ya procesado”).
Los trabajos "ShouldBeUnique" y el middleware que limita la velocidad también evitan tormentas cuando cien mil comandos desencadenan el mismo procesamiento.
Trabajos fallidos, Horizon y alertas que importan
La tabla failed_jobs (o pantalla Horizon) es su cola de errores. Muchos equipos lo activan durante la migración y luego nunca lo consultan.
Configurar:
- Alerta si
failed_jobs> 0 en colas críticas (pagos,notificaciones). - Dashboard Horizon o métrica de Prometheus en
queue_size,jobs_processed,failed_jobs_total. - Procedimiento: que reinicia (
cola:reintentar todo), que elimina después de la corrección, que rastrea el incidente.
Horizon centraliza el monitoreo de Redis: tiempo de espera, rendimiento, trabajadores activos. Sin Horizon, un script cron que verifica la antigüedad del trabajo más antiguo en Redis (LLEN, LRANGE) ya detecta un trabajador muerto.
Despliegue, Supervisor y la trampa del trabajador zombie
Una implementación que reemplaza el código sin reiniciar a los trabajadores a veces ejecuta la versión anterior de los trabajos durante horas. Laravel documenta queue:restart para indicar una recarga elegante.
Lista de verificación de implementación:
php craft queue:restartdespués de actualizar el código.- Supervisor (o systemd) con
autorestart=true. - Separe las colas pesadas (
--queue=default,emails) para no bloquear trabajos urgentes.
En Docker Compose o Kubernetes, un trabajador no es “un contenedor más”: debe tener la misma versión de imagen que la aplicación, las mismas variables de entorno y una verificación de estado que verifique que se esté consumiendo correctamente, no solo que se esté ejecutando.
La cumbre: la cola esconde un fracaso empresarial
Esto es lo que omiten los tutoriales "Colas de Laravel en 5 minutos".
La cola es una promesa diferida. Sin observabilidad y sin una cultura de "trabajos_fallidos", subcontratas el problema al servicio de atención al cliente o a un socio que nunca recibirá tu devolución de llamada.
Decide y avanza sin puntos ciegos
Mapee sus trabajos: cuáles son críticos, cuáles toleran demoras, cuáles deben ser idempotentes. Elige un driver adaptado a tu hosting (Redis en VPS, SQS en la nube). Configure reintentos con retroceso, alertas de falla y cola:reinicio en su proceso de implementación.
Para comparar ofertas con Redis administrado, trabajadores dedicados o monitoreo incluido, explore nuestro directorio y el comparador. Las guías y los artículos por uso ayudan a dimensionar la infraestructura alrededor de su pila PHP.
Prueba concreta: matar a un trabajador en la preparación, enviar diez trabajos, verificar la alerta y el contenido de "trabajos_fallidos". Si no se notifica a nadie en quince minutos, la cola aún no está operativa.
Preguntas frecuentes
¿Qué controlador de cola elegir con Laravel?
Redis o SQS para producción con múltiples trabajadores; La "base de datos" es adecuada para volúmenes pequeños. El controlador sync nunca debe permanecer en producción: oculta la concurrencia y los tiempos de espera.
¿Qué hacer con los trabajos que fallan después de todos los reintentos?
Aterrizan en "trabajos_fallidos". Alerte, analice, corrija y luego vuelva a intentarlo con queue:retry o elimine después del seguimiento; no permita que se acumulen.
¿Debería Horizon estar en un VPS pequeño?
Tan pronto como entran en juego varios trabajadores o trabajos críticos, Horizon simplifica el monitoreo. En un solo proceso, un cron de estado y alertas sobre "trabajos_fallidos" pueden ser suficientes inicialmente.
¿Cómo dimensionar el número de trabajadores?
Separe las colas por tipo de carga y mida el trabajo más lento. Multiplicar trabajadores en una cola bloqueada por llamadas externas solo crea más conexiones paralelas, no un rendimiento más útil.
La próxima vez que una implementación “tenga éxito”, verifique una cosa: ¿hay un trabajador todavía procesando la cola y las fallas aparecen en alguna parte?