Entrevista de Backend: ¿Cómo propagar el contexto de trazas en mensajes asíncronos?

Planteamiento y casos de uso

Una solicitud HTTP publica un mensaje para procesamiento asíncrono. ¿Cómo propagas el contexto de trazas de forma segura a través de reintentos, lotes e inquilinos? Esta pregunta encaja en entrevistas de backend, observabilidad y mensajería. El objetivo es lograr correlación causal a través de los límites de ejecución sin tratar el contexto de la solicitud como autorización permanente o datos de negocio.

Qué evalúan los entrevistadores

• Si comprendes los límites de traceparent, el tracestate opcional y los propagadores.
• Si los spans de productor, procesamiento de mensajes y reintentos tienen relaciones de parentesco claras.
• Si manejas mensajes por lotes, consumo retrasado, colas de mensajes fallidos (dead letters), muestreo y expiración.
• Si evitas que se propaguen baggages sensibles, datos entre inquilinos y señales de confianza falsificadas.

Preguntas para aclarar antes de responder

Confirma el transporte, la durabilidad de los mensajes, el comportamiento de lotes y reintentos, y si los consumidores cruzan servicios o dominios de confianza. Aclara si la relación deseada es para una sola operación de negocio, un solo mensaje o un lote. Pregunta sobre el muestreo, la retención, el aislamiento de inquilinos y si productores externos pueden inyectar contexto. Finalmente, define el manejo de dead letters y si la reproducción manual crea una nueva rama de traza.

Estructura de respuesta de 30 segundos

“El servicio de entrada extrae y valida los encabezados de propagación, y luego inyecta un contexto de traza mínimo al publicar. El consumidor lo extrae, crea un span de consumidor independiente y representa explícitamente reintentos, lotes y dead letters. Entre dominios de confianza, acepto solo campos controlados y descarto baggage sensible; la política de la plataforma rige el muestreo y la expiración, mientras que la reproducción utiliza un nuevo ID de traza vinculado al original.”

Respuesta detallada paso a paso

1. Definir límites: Modela el ingreso HTTP, la publicación del mensaje, el transporte y el consumo como unidades de ejecución separadas con propietarios explícitos de inyección y extracción.
2. Elegir un portador (carrier): Coloca el formato estándar de propagación en los encabezados del mensaje o en metadatos controlados; nunca copies la solicitud completa, tokens de identidad o baggage arbitrario en mensajes duraderos.
3. Modelar spans: El publicador crea un span de productor y el consumidor crea un span de consumidor; para lotes, registra enlaces de mensajes en lugar de simular que el lote es una sola solicitud.
4. Manejar reintentos y dead letters: Otorga a cada intento su propio span y atributo de intento mientras conservas el enlace al evento original; el manejo de dead letters y la reproducción crean una nueva rama.
5. Gobernar la seguridad: Restringe la inyección entre dominios, sanitiza los campos controlados por el usuario, aísla las etiquetas de inquilinos y limita el muestreo, la retención y el tamaño del contexto.

Ejemplo de respuesta de alta calidad

Separaría el contexto estándar, la correlación de negocio y los límites de seguridad. El punto de entrada HTTP extrae solo encabezados de propagación bien formados, valida la versión y longitud, y crea un span de servidor. Al publicar, el span de productor inyecta un contexto de traza mínimo en los metadatos del mensaje, mientras que un ID de evento de negocio inmutable se almacena por separado porque ambos tienen propósitos diferentes. El consumidor extrae los metadatos y crea un span de consumidor; cada operación posterior obtiene su propio span hijo. Un lote no se fuerza bajo el primer mensaje como un único padre: registro un span de lote y enlaces de mensajes acotados. Cada reintento agrega un atributo de intento y de tiempo de espera (backoff) mientras conserva el ID del evento. Una vez que un mensaje entra en una cola de mensajes no entregados (dead-letter queue), la reproducción manual crea una nueva traza vinculada a la original para que la nueva ejecución no se haga pasar por el historial. El baggage de otro inquilino o productor externo se descarta de forma predeterminada; solo los campos de baja sensibilidad aprobados por la plataforma cruzan el límite. Validaría el tamaño del contexto, fallos de extracción, correlación mensaje-consumidor, visibilidad de reintentos y fugas entre inquilinos mediante pruebas y métricas de producción.

Errores comunes

• Tratar un ID de traza como una credencial de autenticación o una clave de idempotencia de negocio.
• Persistir encabezados HTTP completos, entradas de usuario o tokens en un mensaje duradero.
• Colocar el consumo de lotes y todos los reintentos bajo un solo span, distorsionando los tiempos.
• Reutilizar la traza antigua durante la reproducción de una dead letter, ocultando el nuevo intento.
• Hablar de llamadas al SDK sin considerar dominios de confianza, muestreo, retención y control de tamaño.

Preguntas de seguimiento y respuestas

Si un mensaje se reintenta diez veces, ¿cuántos spans deberían existir?

Crea un span distinguible para cada intento de procesamiento real y vincúlalo con el número de intento, el ID del evento y la operación del productor original. Esto expone la latencia por intento sin reportar diez ejecuciones como si fueran una sola.

¿Cómo eliges un padre para un lote?

Crea un span de consumidor para el lote y luego utiliza enlaces acotados o spans hijos para los mensajes que requieran análisis. No elijas arbitrariamente el primer mensaje como padre del lote; conserva las estadísticas a nivel de lote y los ID de correlación cuando el muestreo sea limitado.

¿Puede un cliente externo inyectar tracestate?

Acepta campos conformes al protocolo únicamente como entradas no confiables. Al cruzar un límite de confianza, limita la longitud, las claves y el reenvío, elimina campos sensibles o de alta cardinalidad, y nunca los utilices para autorización.

¿Cómo se mantiene rastreable la reproducción manual de dead letters?

Crea una nueva traza y un span de ejecución para la reproducción, registrando el ID del mensaje original, el operador, el motivo y el lote de reproducción. Vincula las trazas antiguas y nuevas a través de una relación controlada mientras preservas el fallo original inmutable.