Eis uma cena que a maioria dos engenheiros sênior já vivenciou. Um time de talvez 20 pessoas passa um trimestre migrando um monolito que funciona para uma arquitetura de microserviços, dividindo-o em uma dúzia de serviços. O pitch era convincente: deploys independentes, melhor escalabilidade, "a forma como as grandes empresas de tech constroem software." Nove meses depois, o mesmo time está debugando uma falha no checkout que toca quatro serviços, três formatos de logging diferentes, e um distributed trace que mantém perdendo spans justamente onde o bug real está. O release que costumava levar vinte minutos agora leva uma tarde inteira coordenando compatibilidade de versões entre times.
Ninguém planejou para esse resultado. Mas é o resultado padrão, porque a maioria dos times que adota uma arquitetura de microserviços não tem na verdade o problema para o qual microserviços foram construídos para resolver.
O problema que uma arquitetura de microserviços foi realmente construída para resolver
Dividir um sistema em serviços não é sobre limpeza de código. Resolve um problema específico: grande número de engenheiros que precisam trabalhar independentemente em diferentes partes do sistema, fazer deploy em seus próprios cronogramas, e escalar partes separadamente sem se atrapalharem.
Se seu time tem oito ou dez engenheiros, esse problema ainda não existe. Um time desse tamanho consegue revisar o código um do outro, entender o sistema inteiro, e fazer deploy de um monolito junto sem um change advisory board. Uma arquitetura de microserviços não dá nada para esse time. O que ela dá é uma superfície de falha distribuída, chamadas de rede onde costumava ter chamadas de função, e um problema de consistência de dados que uma transação de banco de dados único costumava resolver de graça.
A pergunta que quase ninguém faz antes de migrar é desconfortavelmente simples: o que está realmente lento ou quebrado hoje? Se a resposta honesta é "deploys levam muito tempo" ou "o codebase é uma bagunça," isso é um problema de disciplina de engenharia, não de arquitetura. Resolve com pipelines de CI melhores e limites de módulos claros dentro do codebase existente. Não resolve cortando o sistema em pedaços que agora conversam um com o outro sobre a rede.
Por que microserviços se tornaram a resposta padrão de qualquer jeito
Tem uma razão cultural para isso continuar acontecendo, e vale a pena dizer em voz alta. Microserviços soam como engenharia séria. É o que Netflix faz, o que Amazon faz, o que Uber faz. Colocar isso num roadmap técnico sinaliza ambição, mesmo quando o produto em questão lida com uma fração de um porcento do tráfego que essas empresas lidam.
A parte que se perde é que nenhuma dessas empresas adotou uma arquitetura distribuída porque um blog post disse pra fazer. Fizeram porque tinham milhares de engenheiros tocando o mesmo codebase e fazer deploy de um monolito único tinha se tornado fisicamente impossível sem quebrar algo mais a cada semana. Netflix não dividiu seus sistemas pra ficar bem num keynote. Fez porque coordenar centenas de times ao redor de um único pipeline de deploy tinha parado de funcionar.
Copiar a solução sem ter o problema subjacente é o erro real. É comprar o carro exato que um piloto de corrida usa e esperar que sozinho isso te faça mais rápido. A ferramenta não fabrica o problema que a justificava.
Quando a dor organizacional realmente justifica uma arquitetura de microserviços
Nenhum disso quer dizer que microserviços são sempre a chamada errada. Tem situações reais e específicas onde dividir o sistema é a decisão certa, e vale a pena nomeá-las precisamente, porque a resposta honesta não é "nunca microserviços." É "microserviços quando esse problema específico aparece."
O primeiro e mais comum caso entre empresas que já escalaram: times grandes se atrapalhando dentro de um monolito. Uma vez que você tem 60, 100, ou 150 engenheiros trabalhando no mesmo repositório, merges ficam dolorosos, o deploy de um time bloqueia o de todo mundo, e um bug num módulo de billing pode derrubar checkout porque tudo roda no mesmo processo. Esse é um problema de coordenação real, e dividir o sistema em serviços independentes resolve dando a cada time seu próprio cadence de deploy, seu próprio blast radius, e seu próprio cronograma de release.
O segundo caso é uma necessidade genuína de escalar partes do sistema independentemente. Digamos que um pipeline de processamento de imagem queima dez vezes a CPU do resto da aplicação. Num monolito, isso te força a escalar a app inteira horizontalmente só pra dar mais recursos pra aquela peça. Puxar pra seu próprio serviço deixa escalar contra sua própria curva de demanda sem arrastar o resto do sistema. Isso é diferente de dividir tudo "just in case." É uma decisão dirigida por uma métrica de recurso que já está causando dor hoje.
O terceiro caso, e o mais difícil de enxergar corretamente, é domínios de negócio genuinamente desacoplados. Não "módulos diferentes do mesmo domínio" mas domínios com ciclos de vida separados, regras de negócio separadas, e stakeholders separados. Um sistema de billing e um engine de recomendação, por exemplo, raramente precisam mudar no mesmo cronograma, raramente são donos do mesmo time, e raramente compartilham um modelo de dados natural. Dividir aqueles faz sentido não só tecnicamente mas organizacionalmente.
Note o padrão entre os três: a dor existe antes da mudança de arquitetura. Ninguém migra pra prevenir um problema de escalabilidade hipotético no futuro. Migram porque o problema já está acontecendo e já está custando dinheiro, tempo, ou pessoas.
O custo que ninguém coloca no diagrama de arquitetura
Quando esse problema ainda não existe, adotar uma arquitetura de microserviços não é uma escolha neutra. Tem um custo real, pago em várias frentes de uma vez.
O primeiro é deployment. Indo de "uma app, um deploy" pra "vinte serviços com versões compatíveis que todos precisam ser coordenados" multiplica o número de coisas que podem dar errado. Agora você precisa de versionamento de contrato entre serviços, feature flags pra rollouts graduais, e um pipeline de CI/CD separado por serviço em vez de um.
O segundo é observabilidade. Num monolito, uma stack trace te diz exatamente onde algo quebrou. Num sistema distribuído, o mesmo erro pode ter cruzado cinco serviços antes de aparecer, e sem distributed tracing propriamente implementado (que não é de graça pra construir ou manter) você vai passar horas reconstruindo manualmente o caminho que um único request tomou.
O terceiro é consistência de dados. Num monolith, uma transação de banco de dados te dá atomicidade quase de graça. Numa arquitetura de microserviços, aquela mesma operação agora toca múltiplos bancos de dados independentes, e de repente você está implementando padrões como sagas ou eventual consistency pra resolver um problema que um único `BEGIN` e `COMMIT` costumava lidar.
O quarto é latência de rede. Cada chamada de função que custava nanosegundos é agora uma chamada HTTP ou gRPC atravessando a rede, com seu próprio orçamento de latência, seus próprios timeouts, e seus próprios modos de falha. Um fluxo que era três funções chamando uma à outra em sequência é agora três serviços chamando um ao outro, e qualquer uma daquelas chamadas pode falhar de jeitos que um monolito nunca precisava lidar.
Nenhum desses custos é inerentemente ruim. São o preço de resolver um problema real de coordenação ou escalabilidade. O problema é pagá-los sem precisar, porque daí são custo puro sem nada do outro lado do ledger.
Um teste rápido sobre onde seu time realmente está
Tem um teste simples, ligeiramente desconfortável, que corta através disso. Pergunte: se o time congelasse exatamente como está hoje, o monolito ainda seria um problema? Se a resposta é não, porque a dor é realmente sobre um time que pode crescer, uma parte do sistema que pode precisar escalar "eventualmente," ou uma arquitetura distribuída que só fica mais impressionante, então não tem problema de arquitetura aqui. Tem uma assunção não testada.
Se a resposta é sim, porque times já estão se atrapalhando hoje, porque uma parte do sistema já está consumindo recursos desproporcionais hoje, ou porque dois domínios de negócio já estão se metendo um no outro hoje, então o caso é real. E nesse caso, uma arquitetura de microserviços não é uma trend. É a ferramenta certa pra um problema que já está custando algo.
Nomeie o problema antes de desenhar o diagrama de serviços
Uma arquitetura de microserviços não é boa ou ruim por conta própria. É uma ferramenta com alto custo operacional que só se paga quando resolve um problema de coordenação ou escalabilidade que já existe, não um que você está antecipando. Migrar sem aquele problema não torna um time mais tecnicamente maduro. Dá a um time a mesma complexidade de negócio que tinha antes, agora espalhada por vinte repositórios, com uma superfície de falha maior e menos pessoas que conseguem manter o sistema inteiro na cabeça. Se um time entra numa sala pra fazer essa chamada e ninguém consegue nomear, com números reais, o que está lento ou quebrado hoje, a resposta certa não é "qual arquitetura de microserviços a gente constrói." É ficar no monolito mais um ciclo e consertar o problema que realmente existe.
