Entrevista de Backend: Diseñar una Dead-Letter Queue con reintento seguro

Pregunta y cuándo aplica

Diseña un flujo de mensajes asíncrono en el que los mensajes ingresan a una dead-letter queue (DLQ) después de un número acotado de reintentos y los operadores pueden reproducir mensajes seleccionados tras solucionar la causa. Explica el aislamiento, la investigación, la selección de lotes, los efectos secundarios duplicados y la protección para el tráfico normal.

Los temas de entrevistas de desarrollo de software de Amazon enfatizan la aplicación del conocimiento para resolver problemas. AWS documenta las DLQ como aislamiento para mensajes no consumidos con límites de reintentos y alarmas; Google Pub/Sub documenta dead-letter topics y semántica de reproducción o búsqueda (seek). La clave es un ciclo operativo de recuperación, no solo un diagrama de colas.

Qué evalúan los entrevistadores

• Clasificación de errores transitorios, mensajes venenosos (poison messages), rechazo de negocio y expiración.
• Metadatos para versión, tenant, partición, traza, intentos y motivo de la falla.
• Controles de reproducción: idempotencia, alcance, tasa, aprobación y condiciones de parada.
• Ordenamiento, retención, entrega duplicada y semántica at-least-once.
• Métricas que demuestren la recuperación en lugar de simplemente mover mensajes de regreso.

Preguntas para aclarar antes de responder

• ¿La entrega es at-least-once, at-most-once o exactly-once a nivel de negocio?
• ¿Cuáles fallas son reintentables?
• ¿Durante cuánto tiempo se retienen los mensajes y cuándo pierden valor?
• ¿Se requiere orden para una clave de agregado?
• ¿Los consumidores pueden generar efectos secundarios idempotentes?
• ¿Quién puede inspeccionar, reproducir o eliminar mensajes?
• ¿Cuáles son los SLO normales, la capacidad de la cola y la capacidad de reproducción?
• ¿Una reproducción fallida entra a la misma DLQ o a una replay-DLQ?

Estructura de respuesta de 30 segundos

“Primero defino la semántica de entrega, la retención y las claves de ordenamiento. Los errores reintentables usan un backoff acotado; los mensajes venenosos y de rechazo de negocio van a una DLQ con motivo, intentos, versión e ID de traza. Tras la corrección, un operador crea un lote de reproducción acotado, valida una muestra de forma aislada y reproduce a una tasa limitada. Los consumidores protegen los efectos secundarios con claves de idempotencia. Monitoreo la antigüedad de la DLQ, las fallas de reproducción, los duplicados y la latencia downstream, pausando cuando se cruzan los umbrales”.

Respuesta detallada, paso a paso

Paso 1: Definir la máquina de estados de fallas

Separa los estados normal, reintento, DLQ, corrección manual y replay-DLQ. Las fallas de negocio permanentes no deben reintentarse indefinidamente.

Paso 2: Definir los metadatos del mensaje

Conserva el ID del evento, la clave de idempotencia de negocio, la hora de creación, el tenant o partición, la versión del esquema, los intentos, el ID de traza original y la clase de error. Preserva la carga útil original de forma inmutable.

Paso 3: Establecer reglas de reintento y DLQ

Elige el número máximo de recepciones, el backoff y la retención. AWS SQS documenta restricciones de la cola de origen y de la Region, y recomienda alarmas para la DLQ. Los mensajes expirados o revocados necesitan una disposición auditada.

Paso 4: Hacer segura la reproducción

Una solicitud de reproducción incluye un filtro, versión del consumidor de destino, límite de tasa, tamaño de lote, aprobador y expiración. Valida una muestra primero y luego reproduce en lotes. Aísla la capacidad de reproducción del tráfico normal.

Paso 5: Manejar el ordenamiento y la concurrencia

Cuando el orden importa, particiona por clave de agregado y evita que los consumidores normales y de reproducción procesen la misma clave de forma concurrente. No asumas una entrega exactly-once de extremo a extremo únicamente a partir de la cola.

Paso 6: Proteger los efectos secundarios

Usa IDs de evento o claves de idempotencia de negocio para escrituras condicionales. Los pagos y el correo electrónico necesitan claves de solicitud idempotentes y consulta de resultados; eliminar un mensaje no es una reversión (rollback).

Paso 7: Operar con observabilidad

Monitorea la profundidad de la DLQ, la mayor antigüedad, las clases de error, el throughput de reproducción, las fallas de reproducción, los efectos duplicados y la latencia downstream. Registra el operador, el motivo, el alcance, los tiempos, el resultado y los eventos de detención para cada lote.

Paso 8: Presupuestar capacidad y detener de forma segura

Estima la capacidad de reproducción y mantén a los nuevos consumidores compatibles con los esquemas antiguos. Pausa cuando la causa no esté solucionada, las dependencias se sobrecarguen o la tasa de duplicados aumente; preserva la evidencia.

Ejemplo de respuesta de alta calidad

“Este es un flujo de eventos de órdenes at-least-once. Los tiempos de espera de red se reintentan hasta cinco veces con backoff; los errores de esquema, fallas de autorización y eventos expirados ingresan a la DLQ. Cada mensaje conserva el ID de evento, ID de orden, tenant, versión de esquema, hora de primer encolamiento, intentos, clase de error e ID de traza.

Tras la corrección, un operador elige un tenant y una ventana de tiempo, la versión objetivo, el límite de tasa, el aprobador y la expiración. Se validan cincuenta mensajes en un consumidor aislado y luego la reproducción se ejecuta al diez por ciento del tráfico normal. El estado de la orden usa una escritura condicional indexada por el ID de evento, y las solicitudes de pago reutilizan la clave de idempotencia de negocio. El procesamiento normal y de reproducción para una misma orden no pueden ejecutarse de forma concurrente.

Las alertas cubren la mayor antigüedad, fallas de reproducción, escrituras duplicadas y latencia de dependencias. Cualquier umbral pausa el lote y enruta las fallas repetidas a una replay-DLQ. El registro del lote contiene el filtro, la versión, el operador, el resultado y el motivo de detención”.

Errores comunes

• Tratar a la DLQ como un basurero sin evidencia.
• Reintentar mensajes venenosos indefinidamente.
• Reencolar sin alcance, aprobación o control de tasa.
• Asumir que la cola proporciona exactly-once de extremo a extremo.
• Omitir la idempotencia y generar cobros o correos electrónicos duplicados.
• Ignorar las claves de ordenamiento.
• Monitorear solo la longitud de la cola.
• Compartir capacidad entre la reproducción y el tráfico normal sin protección.

Preguntas de seguimiento y cómo responder

Pregunta de seguimiento 1: ¿Por qué no aumentar los intentos de reintento?

Los reintentos son adecuados para fallas transitorias; los mensajes venenosos y las fallas de negocio permanentes consumen capacidad. Establece límites según el tipo de falla, la retención y el costo de espera para el negocio.

Pregunta de seguimiento 2: ¿Cómo se preserva el orden para una sola orden?

Particiona por clave de orden, bloquea el procesamiento concurrente entre normal y reproducción, y explica cómo las transiciones de estado rechazan eventos obsoletos.

Pregunta de seguimiento 3: ¿Qué pasa si la dependencia no es idempotente?

Usa deduplicación local y consulta de resultados; de lo contrario, exige conciliación manual, compensación o un mecanismo de idempotencia del proveedor.

Pregunta de seguimiento 4: ¿Qué pasa si la reproducción vuelve a fallar?

Envíala a una replay-DLQ separada, retén el lote original y el nuevo error, pausa el filtro afectado y notifica al responsable.

Pregunta de seguimiento 5: ¿Cómo se elige la tasa de reproducción?

Utiliza la capacidad del consumidor, las cuotas de dependencias, el margen disponible en condiciones normales y el tiempo de recuperación. Realiza pruebas de carga con un lote pequeño antes de aumentar la tasa.

Pregunta de seguimiento 6: ¿Cuándo se puede descartar un mensaje?

Solo después de una decisión de negocio explícita de que ha expirado, ha sido revocado o carece de valor, con evidencia de auditoría y un motivo conservado.