Conceitos
Trace context propagation
Intuição
É como uma etiqueta de bagagem que acompanha sua mala em cada conexão de voo: a etiqueta não muda de dono, ela viaja junto de avião em avião, e é só por causa dela que, no fim da viagem, alguém consegue reconstruir todo o trajeto da mala mesmo tendo passado por companhias aéreas diferentes que nunca se falaram diretamente entre si.
Como funciona
Cada span de um trace no Dapper é gerado de forma independente pelo serviço que o executa, mas para que esses spans espalhados por dezenas de processos e máquinas diferentes possam depois ser reunidos numa única árvore, o identificador do trace e o identificador do span pai precisam viajar junto com o próprio pedido, não separadamente. É exatamente esse contexto — qual trace e qual span pai um determinado trecho de código pertence — que o Dapper propaga sem exigir código extra do desenvolvedor: a instrumentação das bibliotecas comuns (camada de RPC, threading, controle de fluxo) carrega esse contexto através de fronteiras de thread, de callbacks assíncronos e de chamadas de rede entre processos. Quando um serviço A chama um serviço B via RPC, a biblioteca de RPC instrumentada embute o trace id e o span id de A na própria chamada, e o serviço B, ao processá-la, cria seu próprio span usando esse span id recebido como parent id. É essa cadeia de parent ids propagados de processo em processo que permite juntar, depois do fato, spans criados independentemente em serviços diferentes numa única árvore de causalidade coerente.
Na prática
Esse mecanismo é a razão pela qual sistemas de tracing modernos precisam propagar cabeçalhos como trace-id e span-id (parent) em toda chamada HTTP ou RPC entre serviços — se um único salto na cadeia (um proxy, uma fila de mensagens, um novo processo) não repassar esse contexto, o trace se quebra em pedaços desconexos e a árvore completa do pedido não pode mais ser reconstruída.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.