O que é e como funciona na prática
O termo aranha grande perna fina é um apelido que surgiu no meio de desenvolvimento brasileiro para designar uma abordagem de arquitetura onde um módulo central muito robusto se conecta a vários serviços externos através de interfaces leve e finas. A metáfora vem literalmente da imagem: um corpo grande no centro e pernas finas irradiando para fora. Nada mais nada menos. O que muita gente não entende quando ouve essa nomenclatura pela primeira vez é que não se trata de um framework que você instala. É um padrão de projeto aplicado de forma consistente. Você constrói um núcleo que centraliza lógica de negócio crítica, autenticação, validação e orquestração, enquanto as bordas do sistema são apenas adaptadores simples que conversam com APIs externas, filas de mensagem, bancos diferentes, e o que mais aparecer no caminho.
Na prática, a implementação começa escolhendo o que vai para o centro. Aqui entra o ponto onde a maioria dos times erra. Eles colocam tudo no núcleo por comodidade. O resultado é exatamente o oposto do desejado: um gigante que vira gargalo e torna qualquer mudança custosa. O núcleo deve conter apenas regras de domínio que realmente justificam centralização. Tudo que é interação com dependência externa fica nas pernas.
👉 Clique no botão abaixo para saber mais sobre o assunto!
aranha grande perna fina na vida real
Eu implementei isso em um projeto de integração financeira onde o núcleo orquestrava requisições para cinco provedores de pagamento diferentes. Cada um tinha SDK, autenticação, formato de resposta e política de retry completamente distintos. A tentação era copiar e colar a lógica em cada chamado. Em vez disso, criei uma interface única com métodos normalizados e deixei cada adaptador resolver sua própria complexidade interna. O núcleo só via contratos, nunca implementações. O problema específico que eu encontrei foi com timeouts assíncronos. Um dos provedores tinha latência imprevisível e às vezes respondia em 200 milissegundos, outras vezes ficava hanging por 30 segundos antes de fechar a conexão. Meu primeiro erro foi tratar todos os adaptadores com o mesmo timeout. Isso significava que o provedor rápido ficava esperando o lento finishar. A solução foi configurar timeouts por adaptador, com um circuito breaker no núcleo que abria o caminho para aqueles que estavam consistentemente lentos. Isso reduziu o tempo médio de resposta do sistema de 8 segundos para cerca de 900 milissegundos.
Um insight contra-intuitivo que poucas pessoas consideram é que pernas muito finas demais podem ser problemáticas. Se cada adaptador for um arquivo de dez linhas sem estrutura, você perde capacidade de testar, logar e monitorar. O ideal é que cada perna tenha pelo menos um teste de integração com stub, um logger estruturado e métricas próprias. O núcleo fica enxuto, mas as pernas precisam de alguma massa. A outra armadilha comum é achar que esse padrão resolve problemas de escala sozinho. Ele não resolve. Se o núcleo processa tudo serialmente, ele continua sendo o gargalo independentemente de quão finas são as pernas. Em cenários de alta concorrência, o núcleo precisa ter filas internas, processamento paralelo e mecanismos de backpressure. Caso contrário, você troca um monolito por um monolito com visual de aranha.
Quando esse padrão não funciona, e existe cenário claro em que não funciona, é quando o domínio naturalmente se divide em domínios independentes com poucas dependências entre si. Nesses casos, uma arquitetura de microsserviços faz mais sentido porque cada serviço seria seu próprio nó central, não uma perna de uma aranha gigante. Forçar a aranha grande perna fina num domínio que pede desacoplamento total gera acoplamento disfarçado de modularidade. Se você está começando a aplicar isso, a dica prática é não tentar implementar tudo de uma vez. Comece com dois adaptadores no máximo. Valide que o contrato entre núcleo e pernas funciona no seu contexto específico. Só então adicione mais complexidade. Sistemas que tentam suportar dez dependentes desde o dia um geralmente terminam com o núcleo reescrito em três meses porque as suposições iniciais estavam erradas.
