Planteamiento y alcance
La propagación de contexto puede hacer que una solicitud sea comprensible a través de los límites del servicio, pero cada servicio downstream puede recibir y registrar en logs los valores propagados. OpenTelemetry documenta Baggage como contexto de nombre/valor adyacente al contexto de rastreo y advierte sobre las implicaciones de seguridad. La habilidad fundamental es el diseño de límites distribuidos, por lo que esta es una pregunta system-design.
Qué evalúan los entrevistadores
Las respuestas sólidas separan el contexto de rastreo de los metadatos de la aplicación, definen una lista de permitidos (allowlist) y la propiedad de los campos, y evitan que los valores confidenciales crucen límites no confiables. Cubren el tamaño de los encabezados, la codificación canónica, el muestreo, los reintentos, los mensajes asíncronos y qué sucede cuando el contexto está mal formado o ausente. También incluyen métricas que demuestran que la propagación es útil sin convertirla en un canal de datos no controlado.
Preguntas para aclarar primero
- ¿Qué protocolos transportan el contexto: HTTP, gRPC, colas o tareas programadas?
- ¿Qué campos son de diagnóstico, cuáles afectan el comportamiento y quién es el propietario de cada campo?
- ¿Qué límites de confianza existen entre inquilinos, regiones y servicios de terceros?
- ¿Se permiten valores en logs, etiquetas de métricas o solo en trazas?
- ¿Cuáles son los presupuestos máximos de tamaño de encabezado, latencia y disponibilidad?
- ¿El contexto mal formado debe ser rechazado, eliminado (stripped) o reemplazado con una nueva raíz?
Estructura de respuesta en 30 segundos
“Definiría un envoltorio (envelope) pequeño y versionado con el contexto de rastreo separado de los campos de negocio aprobados. En cada límite, una biblioteca de políticas valida nombres, tamaño, codificación, alcance del inquilino y confianza del destino; elimina o rechaza valores no permitidos y nunca reenvía secretos. La propagación debe funcionar para extremos sincrónicos y asincrónicos, con encabezados limitados y un comportamiento claro ante la falta de contexto. Mediría fallas de extracción, truncamiento, cobertura de propagación, violaciones entre inquilinos y la tasa de unión de trazas (trace join rate).”
Respuesta paso a paso
Paso 1: Definir el contrato de contexto
Cree un registro de campos con propietario, tipo, longitud máxima, nivel de confidencialidad, retención y destinos permitidos. Mantenga los identificadores de rastreo en el protocolo de rastreo y coloque solo los metadatos de negocio aprobados en un portador separado similar a baggage. Asigne versiones al envelope para que los consumidores puedan rechazar campos críticos desconocidos.
Paso 2: Aplicar la política de límites
Utilice un middleware compartido o una política de sidecar que analice el portador, valide la codificación y el tamaño, verifique el inquilino y la zona de confianza, y emita un portador saneado. Nunca copie encabezados entrantes arbitrarios en solicitudes salientes. Trate las llamadas a terceros y entre inquilinos como nuevas raíces de confianza, a menos que una política explícita permita el reenvío.
Paso 3: Manejar el transporte y los reintentos
Defina portadores equivalentes para HTTP, metadatos de gRPC y atributos de mensajes. Persista solo los campos requeridos para correlacionar un trabajo asíncrono; no serialice secretos en colas. En los reintentos, preserve la relación de rastreo original mientras evita que se confíe en decisiones de negocio duplicadas o desactualizadas sin una revalidación.
Paso 4: Diseñar el comportamiento ante fallas
El contexto mal formado o sobredimensionado debe eliminarse o rechazarse según el riesgo del endpoint, mientras que la solicitud en sí permanece observable con una nueva raíz de rastreo local cuando sea seguro. Exponga contadores codificados por motivo, no valores sin procesar. Haga que la versión de la política y el resultado de su aplicación sean visibles para los operadores.
Paso 5: Operar y demostrar el valor
Rastree la tasa de unión de trazas, las fallas de extracción e inyección, los bytes agregados, el truncamiento, los rechazos de políticas, las violaciones entre límites y los errores de serialización en colas. Muestree de forma segura y evite etiquetas de métricas de alta cardinalidad no acotadas. Agregue pruebas de contrato para cada protocolo admitido y un despliegue canary de políticas antes de exigir el rechazo.
Respuesta modelo
“Trataría el contexto propagado como un canal de datos no confiable. Un registro versionado define qué campos de diagnóstico y de negocio pueden viajar, su confidencialidad y su tamaño. El middleware valida y sanea cada salto, con reglas más estrictas para llamadas a terceros y entre inquilinos; los secretos nunca ingresan a los portadores ni a las colas. El contexto de rastreo se mantiene separado del baggage de negocio. Admitiría HTTP, gRPC y atributos asíncronos, definiría la eliminación frente al rechazo y mediría la tasa de unión, las fallas de políticas, los bytes y las violaciones. Un despliegue canary y métricas con códigos de motivo nos permiten ajustar las políticas sin perder observabilidad.”
Errores comunes
- Reenviar todos los encabezados entrantes → los datos no confiables cruzan los límites → utilice una lista de permitidos y un saneador.
- Poner tokens o PII en el baggage → los logs y servicios downstream pueden exponerlos → mantenga los datos confidenciales fuera.
- Usar baggage como etiquetas de métricas → la cardinalidad y el costo se disparan → registre dimensiones y códigos de motivo acotados.
- Ignorar colas y reintentos → el trabajo asíncrono pierde o confía en contexto desactualizado → defina contratos específicos para el transporte y vuelva a validar.
- Rechazar cada solicitud mal formada → la observabilidad y la disponibilidad se ven afectadas → elija la eliminación o el rechazo según el riesgo del endpoint.
- Sin presupuesto de tamaño → los encabezados causan fallas en los proxies → limite cada campo y el total del portador.
Preguntas de seguimiento
Pregunta de seguimiento 1: ¿Debe propagarse el ID de inquilino (tenant ID)?
Solo cuando el destino esté autorizado para ese inquilino y el valor se valide contra la identidad autenticada. No debe convertirse en una autoridad por sí mismo.
Pregunta de seguimiento 2: ¿Cuál es la diferencia entre el contexto de rastreo y el baggage?
El contexto de rastreo conecta los spans y el estado de propagación. El baggage transporta datos de nombre/valor definidos por la aplicación y, por lo tanto, necesita políticas más estrictas de confidencialidad, propiedad y destino.
Pregunta de seguimiento 3: ¿Cómo se previene el crecimiento de los encabezados?
Establezca presupuestos por campo y totales, rechace o trunque con métricas codificadas por motivo y prefiera una referencia acotada al estado del lado del servidor cuando no se pueda evitar un contexto más grande.
Pregunta de seguimiento 4: ¿Qué sucede en un límite no confiable?
Elimine los campos no aprobados, cree o continúe solo la información de rastreo permitida por la política y registre en logs la decisión de la política sin registrar el valor confidencial.