Prompt y contexto
Esta pregunta encaja en entrevistas de backend, plataforma y sistemas distribuidos. El entrevistador busca el límite claro: SQS trata el mismo ID de deduplicación como un duplicado dentro del intervalo de deduplicación y continúa rastreando ese ID incluso después de que un mensaje se recibe y se elimina; esto no hace que un efecto secundario en una base de datos externa, pago o correo electrónico sea inherentemente exactly-once.
Lo que el entrevistador está evaluando
Una respuesta sólida separa la deduplicación del productor, el orden FIFO, el visibility timeout del consumidor, la confirmación de eliminación y la idempotencia de negocio. AWS define el ID de deduplicación como un token que previene la entrega duplicada; cuando la deduplicación basada en contenido está habilitada y no se proporciona ningún ID, SQS puede derivar uno aplicando un hash al cuerpo del mensaje. La respuesta debe cubrir el intervalo, los reintentos y la observabilidad en lugar de decir "FIFO nunca duplica".
Preguntas de clarificación para hacer primero
Límite semántico
Pregunta si el requisito es la supresión de duplicados a nivel de cola, el procesamiento at-least-once o un efecto de negocio de una sola vez. Mantén separado "un mensaje" de "un cobro".
Entrada de deduplicación
Confirma si el productor genera un MessageDeduplicationId estable, si la deduplicación basada en contenido está habilitada, cómo se eligen los grupos de mensajes y si los reintentos ocurren dentro del intervalo de cinco minutos.
Puntos de falla
Dibuja la línea de tiempo de recepción, procesamiento, escritura del efecto secundario y DeleteMessage. Pregunta qué sucede ante la caída de un consumidor, el vencimiento del visibility timeout, un reintento de red y un timeout en los sistemas downstream.
Estructura de respuesta en 30 segundos
“El ID de deduplicación FIFO evita que el mismo mensaje sea aceptado nuevamente durante el intervalo de cinco minutos y sigue rastreando ese ID; aborda los envíos duplicados a nivel de cola y el ordenamiento, no los efectos secundarios externos exactly-once. Yo usaría una clave de negocio estable para un registro de idempotencia, colocaría el estado del efecto secundario y un outbox en una sola transacción u otro límite seguro contra reintentos, y eliminaría el mensaje solo después del éxito. Una caída puede provocar una reentrega, pero el intento repetido leerá el registro completado.”
Respuesta profunda paso a paso
Paso 1: Establecer la garantía comprobable
Menciona que el mismo ID de deduplicación se trata como un duplicado durante el intervalo de deduplicación de cinco minutos; SQS continúa rastreando el ID después de la recepción y eliminación. No describas el intervalo como una deduplicación permanente.
Paso 2: Separar los controles del productor y del consumidor
El productor utiliza un ID estable para un comando de negocio; el hash del contenido funciona solo cuando el cuerpo representa completamente ese comando. El consumidor necesita una restricción de unicidad duradera en una orden, intención de pago o ID de comando porque un reintento después del intervalo aún puede ser la misma acción de negocio.
Paso 3: Cubrir la ventana de caída (crash window)
Si el consumidor escribe en la base de datos y luego se cae, el mensaje puede reaparecer después de su visibility timeout. Coloca el estado del efecto secundario y la clave de idempotencia en una sola transacción, o utiliza un outbox para una publicación reproducible; elimina solo después de un commit exitoso.
Paso 4: Manejar el orden y los poison messages
Usa el mismo MessageGroupId cuando el orden importe y define un visibility timeout que se ajuste al trabajo. Mueve los mensajes que fallen repetidamente a una dead-letter queue con el ID original, el conteo de recepciones y el motivo del fallo para que los reintentos no bloqueen el grupo indefinidamente.
Paso 5: Verificar y observar
Prueba reintentos del productor, una caída del consumidor después de la escritura, el timeout de DeleteMessage y la reproducción fuera del intervalo. Monitorea claves de negocio duplicadas, ApproximateReceiveCount, profundidad de la DLQ, visibility timeouts y latencia de extremo a extremo; las alertas deben distinguir los duplicados de cola de los duplicados de negocio.
Ejemplo de respuesta de alta calidad
Trato la deduplicación de cinco minutos de SQS como una salvaguarda de transporte, no como una garantía de pago único. El productor crea un ID de comando estable para cada intención de pago y lo reutiliza en los reintentos. El consumidor primero aplica un ID de comando único en una tabla de inbox, luego escribe el estado de la orden y un evento de outbox en la misma transacción, y elimina el mensaje después del commit. Si el proceso se cae después de la escritura, la reentrega encuentra el registro completado y no vuelve a cobrar. Monitorearía los comandos duplicados, los conteos de recepción y la DLQ, e inyectaría fallas durante reintentos dentro de la ventana, fuera de la ventana y de DeleteMessage.
Errores comunes
- Error: Decir que FIFO significa exactly-once permanente. → Por qué falla: Ignora el intervalo de cinco minutos y las caídas del consumidor. → Solución: Especificar el límite temporal del ID y agregar idempotencia de negocio.
- Error: Generar un nuevo ID de deduplicación para cada reintento. → Por qué falla: Un solo comando se convierte en múltiples mensajes. → Solución: Reutilizar un ID de comando estable.
- Error: Eliminar antes de que se complete el procesamiento. → Por qué falla: Una falla downstream se convierte en pérdida de mensajes. → Solución: Eliminar después de un commit exitoso y permitir la reentrega por timeout.
- Error: Depender únicamente del hash del cuerpo. → Por qué falla: Las marcas de tiempo o campos irrelevantes pueden eludir la deduplicación. → Solución: Definir un ID estable explícito para el comando de negocio.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Qué pasa si el mismo comando llega después de cinco minutos?
Utiliza el registro duradero de idempotencia de negocio para decidir si se completó; la deduplicación de la cola reduce las repeticiones en ventanas cortas, pero no puede reemplazar el estado de negocio persistente.
Pregunta de seguimiento 2: ¿Por qué no eliminar antes de procesar?
Eliminar primero convierte una falla downstream en pérdida de mensajes. A menos que la pérdida sea explícitamente aceptable y otra fuente sea confiable, procesa con reintentos antes de la eliminación.
Pregunta de seguimiento 3: ¿Qué problema resuelve un outbox?
Realiza el commit del estado de negocio y un evento pendiente en una sola transacción de base de datos para que la publicación pueda reintentarse de forma segura; los consumidores downstream aún necesitan idempotencia basada en el ID del evento.
Pregunta de seguimiento 4: ¿Cómo demostrarías que no hay cobros duplicados?
Inyecta fallas después de la escritura, durante el timeout de eliminación y después de una reproducción fuera de la ventana. Verifica la restricción de unicidad de la base de datos, la clave de idempotencia del proveedor de pagos y los registros de auditoría en lugar de depender únicamente de las métricas de la cola.