A aresta de dependência que mente para você

Peça o diagrama de arquitetura de um time de plataforma e você vai receber uma de duas coisas: uma página no Confluence com um carimbo de "editado pela última vez há 14 meses", ou um dar de ombros e uma thread no Slack onde três pessoas discutem se o serviço de pagamentos ainda chama o de estoque diretamente ou passou a usar o barramento de eventos naquela migração do Q3 que ninguém terminou de documentar. As duas respostas estão corretas, no sentido de que as duas são o que realmente acontece na maioria dos times a partir de um certo tamanho.

O diagrama não está errado porque alguém foi preguiçoso. Está errado porque um diagrama é uma afirmação sobre o sistema congelada no momento em que alguém o desenhou, e o sistema continuou recebendo deploys. Toda dependência que você não removeu, toda chamada nova que alguém adicionou sob pressão de prazo com a intenção de limpar depois, todo caminho de fallback que só dispara em produção — nada disso aparece num diagrama de caixas e setas a menos que alguém volte e o redesenhe. Ninguém redesenha. Essa distância entre o sistema documentado e o sistema como ele roda de fato é o que chamamos de architectural drift, e não é hipotético: é o estado padrão de qualquer sistema velho o suficiente para ter passado pelas mãos de mais de um engenheiro.

Duas fontes de verdade, e nenhuma delas basta sozinha

A análise estática lê o que você escreveu: faz parsing do código-fonte, resolve os imports, segue os clientes HTTP e os listeners do Kafka, e você fica com um grafo do que o código diz que deveria chamar o quê. É precisa e barata de calcular, mas só conhece caminhos que existem no código-fonte — uma feature flag que está em 100% há oito meses e nunca teve o branch antigo removido ainda parece "em uso" numa leitura puramente estática, e uma chamada que só acontece via reflexão ou uma URL montada dinamicamente pode nem aparecer.

A observação em runtime é o espelho oposto. Observe o tráfego real — qual porta falou com qual container, com que frequência, quão rápido — e você tem exatamente o que está acontecendo agora, sem interpretação necessária. Mas o dado de runtime não tem memória de intenção. Não consegue dizer se uma chamada foi planejada ou é um resquício que ninguém teve coragem de remover, e se a amostra de tráfego perder um job em batch que roda uma vez por noite, essa dependência fica invisível para ela.

Nenhuma das duas está mentindo, exatamente. As duas estão dizendo a verdade sobre uma pergunta diferente.

O que marcar cada aresta realmente compra para você

A jogada útil não é escolher uma fonte em vez da outra — é manter as duas e recusar-se a fundi-las num único fato sem rótulo. Toda aresta de dependência no grafo do Archynt carrega de onde ela veio: static (encontrada no código-fonte, nunca observada ao vivo), runtime (observada em tráfego, não escrita em lugar nenhum), ou both. Esse terceiro estado, confirmed_by: both, é o único em que você pode agir com confiança real — significa que o código e o fio concordam.

As outras duas são onde vivem as descobertas interessantes. Uma aresta só static sem tráfego em runtime há semanas é uma candidata a código morto — uma dependência que você provavelmente pode deletar, e agora você tem evidência em vez de um palpite. Uma aresta só runtime é o oposto e, na nossa experiência, a mais urgente: uma dependência viva que ninguém anotou, o que significa que ninguém é dono dela, ninguém tem alerta configurado para ela, e a próxima pessoa que mexer no serviço que faz a chamada não tem ideia de que ela é crítica até quebrá-la.

Por que essa é uma conversa de risco, não de documentação

É tentador arquivar o drift sob "manter a documentação em dia", que é exatamente por isso que a maioria dos times nunca conserta isso — dívida de documentação perde toda reunião de priorização para qualquer coisa com um ticket e um prazo. O enquadramento mais honesto é que uma dependência de runtime sem dono é ao mesmo tempo superfície de ataque sem monitoramento e um ponto único de falha não planejado. Ninguém está de plantão para uma conexão que nem sabe que existe. É esse o discurso que usamos agora, porque é o que sobrevive ao contato com uma reunião de roadmap.