O básico de externo versus interno em sistemas
Quando alguém pergunta o que é externo e interno, depende muito do contexto. Em software, a diferença costuma ser simples na teoria e irritante na prática. Em rede, é quase o oposto.
O que é externo e interno em termos de dependências
Dependência externa é qualquer coisa que seu código precisa mas que você não controla. Uma biblioteca de terceiros, uma API de pagamento, um SDK de analytics. Dependência interna é o código que você escreveu, mantém, e que roda dentro do mesmo processo ou projeto. A distinção importa porque o ciclo de vida delas é completamente diferente. Quando uma dependência interna quebra, você arruma. Quando uma dependência externa quebra, você espera. Ou pior, você migra. Eu passei duas semanas num projeto em 2022 resolvendo um problema que parecia interno. A equipe inteira caçava bugs no código do app, refatorando módulos, debatendo se era um problema de estado ou concorrência. No final, a culpa era de uma versão do pacote de criptografia que foi atualizada sem changelog. O pacote atualizado passava a aceitar certificates com SHA-1 e o servidor da empresa bloqueava explicitamente esse algoritmo. Ninguém havia pensado em verificar a versão do pacote. O workaround foi travar a versão no lockfile e adicionar um teste de integração que chamava a função de handshake periodicamente.
Isso me leva a um ponto que beginners sempre ignoram. Versão fixa no lockfile não é suficiente. Você precisa de um monitoramento que te avise quando uma nova versão está disponível. Sem isso, você vira refém de versões obsoletas por medo de quebrar produção.
Interface de rede: externo versus interno
Em infraestrutura, externo e interno geralmente se referem a NICs e sub-redes. Interface externa é a que conecta sua aplicação à internet pública. Interface interna é a que se comunica com outros serviços dentro do datacenter ou VPC. A regra prática é simples: dados sensíveis nunca trafegam pela interface externa. Senhas, tokens, chaves de API ficam restritos à rede interna. Isso parece óbvio até acontecer o vazamento.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O problema real aparece em containers e orquestradores. Quando você expõe um serviço internamente via service mesh e esquece de remover a regra de firewall que permite acesso externo, ele fica acessível de qualquer lugar. Já vi isso acontecer com um serviço de health check que tinha uma endpoint administrativa acidentalmente mapeada para o load balancer público. Demorou três horas para descobrir porque o logging estava configurado pra gravar em arquivo local, não em um aggregator central. Configurar corretamente a separação entre essas redes exige pelo menos três coisas: security groups bem definidos, DNS interno com zone separada, e verificação periódica de que nenhuma regra de routing permite fallback para a interface externa quando a interna cai.
Arquitetura de classes: visibilidade interna e externa
Em linguagens como Java, Ce TypeScript, externo e interno aparecem como modifiers de visibilidade. Público e privado. Protegido e package-private. O erro mais comum é expor demais. Criar uma classe pública quando ela deveria ser interna, ou retornar um objeto mutável de um método público. Isso quebra o encapsulamento e torna a API instável. Se você expõe uma lista pública, qualquer consumidor pode modificar o conteúdo. Melhor expor um iterator ou uma cópia imutável.
Do lado oposto, há o problema de over-encapsulation. Quando tudo é privado e não há forma razoável de testar ou estender, você acaba escrevendo testes que dependem de reflection só pra acessar campos. Isso é um sinal claro de que a arquitetura precisa ser revisada, não de que reflection é a solução.
Como definir o limite na prática
Não existe uma regra universal. O que funciona pro backend de alta frequência falha num sistema embarcado com 256MB de RAM. O que eu recomendo como ponto de partida é mapear todas as fronteiras do sistema. Cada chamada de rede, cada leitura de disco, cada importação de módulo é uma fronteira. Classifique cada uma como interna ou externa baseado em três critérios: controle, confiabilidade e custo. Se você não controla, não confia 100% e custa caro em latência ou dinheiro, é externa. Tudo o resto tende a ser interno.
Uma armadilha comum é tratar cache como dependência interna. Redis ou Memcached são infraestrutura, sim, mas eles falham. Eles morrem. Eles ficam lentos. Se seu código assume que o cache está sempre disponível, você vai ter picos de latência ou erros em cascata quando o cache cair. Trate cache como externo com fallback para banco de dados. É mais código, mas evita dor de cabeça. A separação entre externo e interno não é apenas técnica. Ela define quem é responsável pelo quê. Quando o time sabe onde termina a responsabilidade deles e começa a responsabilidade de outro grupo, o debugging fica muito mais rápido e os SLAs fazem sentido.
