Quando Não Usar Microsserviços: O Imposto Oculto da Complexidade Distribuída

Poucos movimentos arquiteturais queimaram mais capital de risco e orçamentos de TI corporativa na última década do que a adoção prematura de microsserviços.

Todos nós já vimos esse filme: uma organização com 15 a 25 engenheiros de software e um perfil de tráfego moderado (algumas centenas de requisições por segundo) decide que sua aplicação existente é "legado". Inspirada por palestras de conferências da Netflix, Uber ou Amazon, a equipe de arquitetura anuncia uma reescrita do zero: eles dividem o domínio em 40 microsserviços minúsculos, cada um com seu próprio repositório Git, seu próprio pipeline de CI/CD, seu próprio contêiner Docker, seu próprio banco de dados e um complexo service mesh do Kubernetes unindo tudo.

Dezoito meses depois, o resultado é quase sempre o mesmo:

• A velocidade de entrega de funcionalidades entrou em colapso: Adicionar um único atributo novo a uma fatia de cliente agora exige pull requests coordenados, atualizações de versão e coreografia de implantação em seis microsserviços diferentes.
• A depuração exige uma agência de detetives: Quando o checkout de um cliente falha, nenhum engenheiro sozinho entende a máquina de estados ponta a ponta em filas assíncronas, tentativas e transações compensatórias.
• A fatura de nuvem triplicou: Embora o tráfego de usuários tenha crescido apenas 15%, os custos da AWS/GCP explodiram devido à margem de capacidade ociosa redundante de contêineres, taxas de transferência de rede entre zonas de disponibilidade (Cross-AZ) e ingestão de rastreamento de observabilidade.

Como Martin Fowler e Sam Newman, dois dos primeiros pioneiros que documentaram microsserviços, alertaram repetidamente: microsserviços quase nunca devem ser o seu ponto de partida.

1. Que problema os microsserviços foram realmente inventados para resolver?

Os microsserviços não foram inventados para tornar o código "mais limpo" ou mais rápido. Uma chamada de função em memória dentro de um único processo é executada em nanossegundos e não pode falhar devido a um pacote de rede perdido. No momento em que você divide essa chamada de função entre dois microsserviços separados por rede, o tempo de execução salta em cinco a seis ordens de magnitude (milissegundos), e você herda imediatamente as Falácias da Computação Distribuída: partições de rede, tempos limite, mensagens fora de ordem e falhas parciais.

Por que, então, empresas como Netflix e Amazon adotaram microsserviços? Para resolver a Lei de Conway em escala organizacional massiva. Quando você tem 1.500 engenheiros em 180 squads autônomos enviando código simultaneamente, coordenar um único binário de implantação monolítico e um único banco de dados compartilhado torna-se um gargalo organizacional. Microsserviços trocam simplicidade de execução e eficiência de infraestrutura em troca de desacoplamento organizacional em grande escala de pessoal.

Se você tem 15 ou 30 engenheiros e 45 microsserviços, o que significa que cada desenvolvedor está lidando com dois ou três serviços, você está pagando 100% do Imposto de Complexidade Distribuída enquanto coleta 0% do benefício organizacional.

2. Os cinco impostos ocultos dos microsserviços prematuros

Antes de dividir um sistema em serviços distribuídos, todo CTO e Arquiteto Principal deve quantificar os cinco impostos compostos que acompanham cada limite de rede:

Até mesmo gigantes da nuvem reconheceram publicamente essa matemática. Quando a equipe de monitoramento de qualidade de áudio e vídeo do Amazon Prime Video consolidou seus microsserviços distribuídos e funções de passo sem servidor de volta a um único processo monolítico, eles reduziram seu custo de infraestrutura em mais de 90% enquanto escalavam para maior rendimento, simplesmente eliminando a sobrecarga absurda de serializar e enviar estado de alto volume através de limites de rede.

3. O padrão inteligente: O Monolito Modular

Rejeitar microsserviços prematuros não significa escrever código espaguete onde arquivos de controladoras consultam diretamente 200 tabelas de banco de dados aleatoriamente. A falsa dicotomia entre um "Monolito de Bola de Lama" e "Microsserviços" ignora o caminho intermediário superior praticado por organizações de engenharia de elite como o Shopify: o Monolito Modular.

Em um Monolito Modular, todo o código compila e é implantado como um único artefato operacional (ou um pequeno punhado de serviços de granulação grossa), mas a base de código interna é estritamente particionada em domínios de negócios isolados:

1. Limites de Módulo Impostos: O módulo Billing não pode importar diretamente classes internas ou consultar as tabelas de banco de dados privadas dos módulos Inventory ou Identity. Ele só pode interagir com eles por meio de interfaces públicas explícitas e versionadas no código, verificadas automaticamente por regras de linter em CI/CD (como ArchUnit, Packwerk ou referências de projeto TypeScript).
2. Separação Lógica de Esquema: Mesmo dentro de um único cluster PostgreSQL, cada módulo de domínio possui suas próprias tabelas (ou esquemas), evitando o acoplamento acidental de JOIN entre domínios.
3. Zero Sobrecarga de Rede: Como todos os módulos executam dentro do mesmo processo e espaço de memória, as implantações são atômicas, ambientes de desenvolvimento locais iniciam em segundos em um laptop e as faturas de nuvem permanecem enxutas.

E note a melhor parte: se uma equipe não consegue manter limites limpos dentro de um Monolito Modular com imposição do compilador, ela nunca manterá limites limpos em 40 microsserviços. Eles simplesmente construirão um Monolito Distribuído, onde cada serviço chama todos os outros serviços de forma síncrona, e se um serviço cair, a empresa inteira cairá.

4. Os três gatilhos legítimos para extrair um microsserviço

Uma vez que seu Monolito Modular tenha limites limpos, extrair um módulo específico para um microsserviço independente leva dias em vez de meses. Você deve puxar esse gatilho apenas quando pelo menos uma destas três condições concretas for atendida:

1. Perfil de Computação ou Recurso Assimétrico: Um módulo específico requer hardware especializado (como inferência de GPU, transcodificação pesada de vídeo ou processamento massivo de grafos em memória) que escala em uma curva completamente diferente da sua API CRUD principal.
2. Isolamento Estrito de Falhas ou Conformidade: Um cofre crítico de processamento de pagamentos (escopo PCI-DSS) ou webhook de ingestão de alta disponibilidade deve permanecer ativo mesmo se o resto da aplicação estiver passando por manutenção.
3. Autonomia Organizacional Real em Escala: Sua equipe de engenharia ultrapassou 50 a mais de 80 engenheiros, e linhas de negócios independentes precisam de cadências de lançamento e pilhas de tecnologia completamente separadas.

Construa para a escala e tamanho de equipe que você tem nos próximos 18 meses, não para a escala de fantasia de uma gigante de tecnologia de 5.000 engenheiros.

Continue lendo: explore o Guia de Arquitetura Escalável e FinOps em Nuvem na Prática: Reduzindo Gastos com AWS e GCP.

---

Referências verificáveis e leitura adicional

• Fowler, M. (2015). MonolithFirst & Microservice Premium. martinfowler.com.
• Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems (2nd Edition). O'Reilly Media.
• Conway, M. E. (1968). How Do Committees Invent?. Datamation, 14(4), 28-31.