Una cola de trabajos permite ejecutar tareas fuera del camino inmediato de una petición: enviar notificaciones, procesar archivos o sincronizar datos. Pero cuando entran más trabajos de los que los consumidores pueden completar, se forma un backlog. El retraso puede hacerse visible como una confirmación tardía, datos desactualizados o tareas que nunca terminan, con impacto tanto para los usuarios como para los equipos que operan la aplicación.
Para decidir cómo actuar no basta con mirar cuántos mensajes están pendientes. Importan su antigüedad, la velocidad a la que llegan y se completan, el tipo de trabajo y el estado de las dependencias. Añadir consumidores puede ayudar si falta capacidad, pero también multiplicar las consultas a una base de datos ya saturada. La respuesta segura empieza por medir y reconocer el patrón.
Qué revela el backlog y qué métricas faltan
El número de trabajos pendientes es una fotografía, no una explicación. Puede crecer durante un pico y reducirse después sin intervención, o permanecer estable mientras el trabajo más antiguo envejece. Por eso, al evaluar cómo controlar el backlog de una cola PHP, conviene observar conjuntamente:
- Tasa de entrada: trabajos aceptados por unidad de tiempo.
- Tasa de salida: trabajos completados por unidad de tiempo, diferenciando completados de intentos fallidos.
- Antigüedad: cuánto lleva esperando el trabajo más antiguo, además de percentiles de espera si están disponibles.
- Duración de procesamiento: cuánto tarda cada tipo de trabajo y cómo cambia esa duración.
- Errores y reintentos: proporción de fallos, número de intentos y presencia de trabajos enviados a una cola de errores o cuarentena.
- Estado de consumidores y dependencias: procesos activos, reinicios, uso de CPU y memoria, conexiones a base de datos y latencia de servicios externos.
La tasa de salida debe representar trabajo útil completado: contar cada intento como una tarea drenada puede ocultar un ciclo de fallos y reintentos. También es importante segmentar por cola o clase de tarea. Una media global puede disimular que un tipo de trabajo está bloqueando a los demás.
Diagnostica el patrón antes de cambiar capacidad
Compara las métricas en una ventana temporal adecuada para la operación y con el comportamiento habitual del sistema. Los patrones orientan la investigación, pero no prueban por sí solos la causa.
- Entrada sostenidamente superior a salida: puede faltar capacidad, haber aumentado el volumen o alargarse la duración de los trabajos. Revisa cambios recientes, composición del tráfico y tiempos por tipo de tarea.
- Consumidores activos, pero salida casi nula: busca procesos bloqueados, esperas indefinidas, deadlocks, agotamiento del pool de conexiones o llamadas externas sin límites de tiempo. Revisa logs y trazas correlacionadas por identificador de trabajo.
- Duración y latencia de dependencias en aumento: los consumidores pueden estar esperando a la base de datos, una API o el almacenamiento. Más procesos pueden elevar la contención y empeorar la latencia.
- Fallos repetidos en los mismos trabajos: podría tratarse de datos inválidos, una condición no recuperable o un defecto. Comprueba la política de reintentos: reintentar demasiado pronto puede crear una tormenta de carga.
- Una cola crece mientras otras avanzan: revisa prioridades, reparto de consumidores y si una clase de trabajo monopoliza los recursos.
Busca también cambios de configuración y despliegues recientes. Confirma que la telemetría distingue un consumidor ocupado de uno vivo que no progresa; una comprobación de proceso activo no garantiza que se estén completando trabajos.
Estima la capacidad de drenaje con datos observados
Si la tasa de salida sostenida supera la tasa de entrada, la cola puede reducirse mientras se mantenga esa diferencia. Como aproximación operativa, el tiempo para procesar el backlog depende del número pendiente dividido por la capacidad neta de drenaje: capacidad de salida menos entrada durante el mismo periodo. Si esa diferencia es cero o negativa, aumentar el tiempo de espera no resolverá la acumulación.
La estimación es orientativa, no una promesa de hora de recuperación. Supone que el ritmo se mantiene y que los trabajos tienen una mezcla y un coste parecidos. Unos pocos trabajos largos, reintentos o límites de una dependencia pueden cambiar el resultado. Usa tasas observadas bajo carga real y vuelve a estimar tras cada intervención. Para tareas con distintos costes, calcula por clase de trabajo o mide el tiempo de servicio, no sólo el número de mensajes.
Intervén en orden y con límites
Prioriza medidas reversibles y acotadas. Antes de cambiar el número de consumidores, acuerda qué impacto puede tolerar cada dependencia y cómo revertir el cambio.
- Contén nuevas entradas si es posible: pausa productores no esenciales, aplica límites o aplaza tareas de baja prioridad. Evita descartar trabajos sin una regla de negocio, registro y mecanismo de recuperación.
- Aísla trabajos problemáticos: limita intentos, aplica espera progresiva cuando corresponda y deriva fallos persistentes a una cola de errores revisable. No ignores esos trabajos: pueden requerir corrección y reprocesamiento.
- Protege la prioridad: separa tareas urgentes de las de mantenimiento o procesamiento masivo, y verifica que las prioridades no condenan a las colas menos urgentes a esperar indefinidamente.
- Ajusta concurrencia gradualmente: modifica consumidores en pasos pequeños y observa rendimiento y saturación. Mantén límites coherentes con conexiones disponibles, CPU, memoria y cuotas de servicios externos.
- Corrige la causa: si hay consultas lentas, bloqueos o llamadas sin timeout, resuelve ese cuello de botella antes de mantener más procesos trabajando en paralelo.
La idempotencia es especialmente importante cuando un trabajo puede ejecutarse más de una vez. Diseña efectos externos y escrituras para tolerar reintentos o incorpora mecanismos de deduplicación adecuados. Confirma también qué ocurre si el consumidor se detiene después de realizar el efecto, pero antes de confirmar el mensaje.
Define umbrales y un procedimiento de recuperación
Establece umbrales a partir de los requisitos de servicio, no de un número universal. Una alerta puede combinar la antigüedad máxima o percentil de espera, la tendencia del backlog, la diferencia entre entrada y salida y la tasa de errores. La antigüedad suele conectar mejor con el impacto para el usuario que un recuento aislado; el volumen ayuda a dimensionar la magnitud.
Documenta quién interviene, qué colas puede pausar, qué dependencias debe consultar y qué cambios requieren aprobación. Durante el incidente, registra hora, hipótesis, acción y efecto observado. Tras cada ajuste, verifica que la tasa de salida aumenta sin que suban de forma inaceptable la latencia de base de datos, los errores externos, el uso de recursos o los fallos de la aplicación.
Considera la recuperación confirmada cuando la antigüedad y el volumen bajan de manera sostenida, los trabajos se completan correctamente y las dependencias vuelven a un nivel estable. No declares resuelto el problema sólo porque disminuya el contador: podría haber mensajes descartados o acumulados en otra cola.
Lista de comprobación para prevenir otra acumulación
- ¿Se miden entrada, salida útil, antigüedad, duración y reintentos por cola?
- ¿Los trabajos tienen límites de tiempo y una política de reintentos finita y adecuada?
- ¿Hay alertas por falta de progreso, no sólo por volumen?
- ¿La concurrencia máxima respeta los límites de las dependencias compartidas?
- ¿Se puede aislar una clase problemática sin detener todo el procesamiento?
- ¿Existe un procedimiento documentado para pausar, reanudar y reprocesar con seguridad?
- ¿Se revisan las métricas y los efectos secundarios después de cambios de código, carga o configuración?
Una cola sana no es necesariamente una cola vacía: puede haber variaciones normales. El criterio práctico es que los trabajos se completen dentro del nivel de servicio previsto, que los fallos sean visibles y que el sistema conserve margen para absorber picos. Medir ese comportamiento permite actuar antes de que una acumulación se convierta en una interrupción para los usuarios.
