Trabalhando com sistemas que se conectam de verdade
A primeira coisa que todo mundo aprende é que interdependência significa quando duas coisas precisam uma da outra para funcionar. Mas isso é a definição de livro. O que importa na prática é o que acontece quando uma parte muda e quebra a outra sem avisar. O que é interdependencia em projetos reais é basicamente isso: você tem componentes, pessoas, equipes ou serviços que dependem uns dos outros de formas que não são óbvias até que algo estoure. E quando estoura, geralmente é na pior hora possível.
Como eu descobri isso na unha
Em 2019, eu estava gerindo um projeto de integração entre um sistema legado de ERP e uma API nova que estávamos construindo do zero. A equipe que mantinha o legado dizia que tudo estava "estável". A nossa equipe de API dizia que estava "pronta para produção". Ambos tinham razão e ambos estavam errados. O problema era que a API enviava payloads em JSON com campos em camelCase, mas o ERP esperava campos em snake_case e ainda por cima truncava qualquer campo maior que 32 caracteres. Ninguém tinha documentado essa limitação de 32 caracteres. Ninguém tinha testado campos longos. Quando fizemos o deploy, os primeiros 47 registros foram corrompidos porque nomes de produtos maiores que 32 chars simplesmente sumiam no cadastro.
A correção foi rápida em teoria: fizemos um mapeamento campo a campo com conversão de cases, um validador de tamanho antes do envio e um job de reparación que recuperou os 47 registros. Na prática, levou 3 dias de trabalho extra, um hotfix às 2 da manhã e uma conversa muito desagradável com o cliente.
A regra que ninguém ensina
A maioria dos profissionais trata interdependência como um diagrama bonito no projeto inicial. Depois esquece que ele existe. O erro comum é assumir que a interface entre dois sistemas é fixa. Em vez disso, trate toda interface como temporária e potencialmente instável até provar o contrário por testes de contrato, não por boas intenções. Contrato de serviço é o termo certo aqui. Você define exatamente o que cada lado espera receber e devolver. Não é uma descrição textual. É um esquema formal — OpenAPI, GraphQL schema, ou até um arquivo JSON Schema que ambas as partes concordam. Qualquer mudança que quebre o contrato gera um erro visível no teste, não na produção.
Um insight que custa caro ter
Aqui vai algo que raramente se lê em lugar nenhum: interdependência alta não é um problema técnico, é um problema de comunicação. Técnico se resolve com abstração. Comunicação se resolve com reuniões chatas, documentação atualizada e reuniões chatas novamente. Quase todo projeto onde eu vi interdependência causar falha grave, a raiz era uma suposição não verificada. Um time assumiu que o outro faria X. O outro time assumiu que já tinha sido comunicado sobre Y. Ninguém verificou. Resultado: dois workstreams avançando paralelamente em direções diferentes por semanas.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A forma mais simples de evitar isso é um artefato chamado matrix de dependências. Uma planilha simples com três colunas: qual sistema/equipe entrega quê, qual sistema/equipe recebe, e qual é a interface/contrato documentado entre eles. Você preenche isso no início do projeto e atualiza toda vez que algo muda. Leva 20 minutos e evita semanas de dor de cabeça.
Limitações que todo mundo ignora
Interdependência bem gerenciada funciona bem até o momento em que o volume aumenta. Especificamente: testes de integração ficam lentos e frágeis. Quanto mais sistemas interligados, mais tempo leva para subir o ambiente de teste, mais pontos falham aleatoriamente e mais trabalho dá para manter os dados de teste confiáveis. Se você tem mais de cinco sistemas com interdependência forte entre si, o custo de teste de integração cresce exponencialmente, não linearmente. A partir desse ponto, o modelo tradicional de teste conjunto já não escala. As alternativas são: usar contratos mockados em testes unitários para isolar cada sistema, ou adotar uma estratégia de contract testing com ferramentas como Pact ou Spring Cloud Contract.
Outra limitação prática: equipes humanas têm turnover. Se a pessoa que sabia como o sistema A se conectava com o sistema B sai da empresa, e essa informação só existia no head dela, você perdeu a dependência mapeada. Por mais absurdo que pareça, esse é um dos cenários mais comuns de falha em interdependência.
Resumo prático para não errar
1. Mapeie todas as interdependências no início do projeto com uma matrix documentada. Isso leva 20 minutos e é o investimento com maior retorno que existe. 2. Defina contratos formais para cada interface. Nada de "a gente combina depois".
3. Teste os contratos regularmente, não apenas no final do desenvolvimento. 4. Mantenha a matrix atualizada quando qualquer coisa mudar. Se a documentação desanda, você volta para o caos em duas semanas.
5. Aceite que interdependência alta adiciona overhead constante ao projeto. É o preço de construir coisas conectadas. Não dá para eliminar, só gerenciar.
