# Dead-letter queue: qué es y cómo usarla > Una dead-letter queue separa mensajes que agotaron sus reintentos para inspeccionarlos y decidir qué hacer. Esta guía explica límites, reintentos, retención y reprocesamiento seguro. - URL canónica: https://visteesto.com/nota/dead-letter-queue-que-es-como-usarla - Autor: [Martin Rodriguez](https://visteesto.com/autor/martin-rodriguez) - Publicado: 2026-09-30T18:00:00.000Z - Actualizado: 2026-09-30T18:00:00.000Z - Sección: Tecnología - Tema: dead-letter-queue-mensajeria - Idioma: es - Consulta principal: dead-letter queue qué es y cómo usarla ## Resumen verificable - Una dead-letter queue separa mensajes que agotaron sus intentos de entrega para inspección posterior. ([evidencia](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)) - El umbral de reintentos y el motivo del descarte dependen de la plataforma de mensajería. ([evidencia](https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues)) - Los dead-letter topics permiten apartar mensajes no confirmados tras varios intentos. ([evidencia](https://cloud.google.com/pubsub/docs/dead-letter-topics)) - Reinyectar mensajes requiere validar payload, versión del consumidor y riesgo de duplicados. ([evidencia](https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues)) ## Aporte editorial de VisteEsto VisteEsto convierte la definición en un procedimiento operativo: separar fallas transitorias de errores de contrato, medir antigüedad y documentar la decisión antes de reinyectar mensajes. ## Qué es una dead-letter queue Una dead-letter queue (DLQ), o cola de mensajes fallidos, es un destino separado para mensajes que no pudieron procesarse después de los intentos permitidos. En vez de bloquear indefinidamente la cola principal, el sistema aparta esos mensajes para inspeccionarlos y decidir si se corrigen, se reintentan o se descartan. AWS y Azure documentan este patrón para sus servicios de mensajería. La DLQ no arregla el error por sí sola. Conserva el mensaje y su contexto para que el equipo pueda encontrar la causa: datos inválidos, una dependencia caída, un cambio de contrato o un límite alcanzado. En algunos servicios, el mensaje conserva propiedades de entrega y la razón del descarte, pero el formato exacto depende de la plataforma. ## Cuándo conviene usarla Una cola de fallos es útil cuando un mensaje problemático no debería impedir que continúen los demás. El límite de reintentos evita gastar recursos en un caso que seguirá fallando y permite que la cola principal mantenga su ritmo. Google Cloud explica un mecanismo equivalente con dead-letter topics para mensajes que no fueron confirmados tras varios intentos. El umbral debe reflejar el tipo de error. Un timeout transitorio puede merecer algunos reintentos con espera, mientras que un esquema inválido necesita corrección o rechazo. Si todos los mensajes terminan en la DLQ, el problema está en el consumidor, las credenciales o el contrato; moverlos de vuelta sin diagnóstico sólo repite la falla. ## Guía para operar una dead-letter queue Definí qué información se guarda: identificador, fecha, cantidad de entregas, error observado y versión del consumidor. Separá mensajes que pueden reprocesarse de los que necesitan una corrección manual. La política de retención debe ser suficiente para investigar, pero no tan larga como para ocultar un problema de producción. Creá un flujo de revisión con permisos limitados. Antes de reinyectar, validá el payload y probalo con la misma versión que falló. Registrá cada movimiento para saber cuántos mensajes volvieron a la cola, cuántos se descartaron y por qué. Una métrica de profundidad de DLQ y una alerta por antigüedad suelen ser más útiles que contar sólo errores de la aplicación. ## Errores frecuentes y límites del patrón Una DLQ no debería ser un depósito permanente ni un reemplazo de observabilidad. Si los mensajes contienen información sensible, aplicá el mismo control de acceso y cifrado que en la cola principal. También revisá el orden: algunas plataformas pueden romper el orden original al mover o reinyectar mensajes, y el comportamiento cambia según el servicio. Documentá qué ocurre cuando la DLQ llega a su capacidad o vence la retención. La decisión puede ser reintentar, corregir y reinyectar, enviar a un flujo manual o eliminar con evidencia. El patrón funciona cuando hace visible el fallo y protege el flujo normal, no cuando oculta errores detrás de una segunda cola. ## Fuentes consultadas - Fuente primaria: [AWS SQS: Dead-letter queues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) - Fuente primaria: [Azure Service Bus: Dead-letter queues](https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues) - Fuente primaria: [Google Cloud Pub/Sub: Dead-letter topics](https://cloud.google.com/pubsub/docs/dead-letter-topics) ## Imágenes y licencias - Diagrama editorial de una cola principal que deriva mensajes fallidos a una dead-letter queue. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/dead-letter-queue-que-es-como-usarla). - Flujo de reintentos que termina en una dead-letter queue. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/dead-letter-queue-que-es-como-usarla). - Checklist para revisar y reprocesar mensajes fallidos. Autor: VisteEsto. Licencia: [VisteEsto editorial](https://visteesto.com/terminos). [Origen](https://visteesto.com/nota/dead-letter-queue-que-es-como-usarla). ## Cómo citar Citar título, autor, fecha de publicación o actualización y la URL canónica. Las afirmaciones centrales incluyen su evidencia directa arriba. Esta versión Markdown es una representación accesible; la nota HTML canónica es la fuente editorial de referencia.