Una cola sirve cuando conviene aceptar rápido una petición y completar el trabajo después, cuando depende de servicios inestables o exige controlar el caudal. También añade otro runtime, resultados demorados y posibles duplicados. Añádela para resolver un cuello de botella concreto, no solo porque los diagramas se ven mejor.
Devuelve un ID y estado “aceptado/en curso”, no un éxito que sugiera que informe, correo o pago ya terminó. Define cómo consultar, qué significa cancelar y si se reintenta automáticamente o requiere revisión.
| Carga | La cola ayuda si... | Aún hay que definir... |
|---|---|---|
| Efectos de webhook | El proveedor espera acuse rápido. | Firma, aceptación duradera, dedupe y orden. |
| Informes o exportaciones | Tarda o necesita más recursos. | Visibilidad, cancelación, caducidad y progreso. |
| Sincronización con API externa | Límites o caídas no deben bloquear usuarios. | Backoff, presupuesto, vigencia y conciliación. |
| Notificaciones | Puede retrasarse sin cambiar la transacción confirmada. | Preferencias, duplicados y estado visible. |
Mantén síncrono el trabajo que exige respuesta autorizada inmediata y cabe en el presupuesto de la petición. Una cola no acelera un algoritmo caro; cambia quién espera y cómo se observa.
Un fallo típico es guardar un pedido y caer antes de publicar el mensaje. Outbox transaccional registra estado y evento pendiente en la misma transacción; un dispatcher publica y marca entrega. El consumidor aún debe tolerar duplicados si el proceso cae tras publicar pero antes de guardar éxito. Para riesgos menores puede bastar una tabla de jobs persistida con recuperación explícita.
Muchas colas pueden repetir mensajes tras timeout o crash. Asigna ID estable a la operación, aplica unicidad o registro de idempotencia y haz idempotentes los efectos externos. Confirma/elimina solo tras completar de forma duradera. Si el worker supera el visibility timeout, extiéndelo o divide el trabajo para impedir consumo paralelo.
Reintenta fallos temporales de red, rate limit y dependencias con backoff exponencial y jitter. No repitas sin fin entradas malformadas ni permisos inválidos. Limita intentos y duración; después pasa el mensaje a dead letter/cuarentena con motivo y correlación. Ofrece replay seguro que conserve el ID lógico y registre un nuevo intento.
Limita profundidad o antigüedad y decide qué ve el usuario si crece el backlog. Escala consumidores solo si el destino puede absorberlo. Si llegan más tareas de las que se procesan, más workers saturan base o partner. Aplica límites de concurrencia, lote, equidad por cliente y control al productor. La edad suele explicar más que el número de mensajes.
Mide aceptado, en cola, iniciado, reintentado, terminado y fallido con horas e IDs de correlación. Alerta sobre mensaje más antiguo, retries, DLQ, errores del consumidor y throttling. Minimiza payloads y datos sensibles en logs. Retención de mensajes y de historial de jobs son políticas diferentes.
Una cola gestionada, un worker y una tabla de estado suele bastar. No introduzcas clúster de broker y orquestación propia antes de necesitarlos. Documenta responsable, despliegue/rollback, mensajes venenosos, autorización de replay y qué ocurre si la cola no está disponible.
Las colas separan aceptación y finalización, pero trasladan complejidad a retries, duplicados, visibilidad y operación. Persiste intención, publica de forma fiable, procesa con idempotencia, limita reintentos y expón estado. Añade colas para resolver un problema real y conserva un modelo que el equipo pueda operar.