Uma equipe de oito pessoas mantém vinte microsserviços. Cada release toca quatro repositórios. Uma transação que antes era uma chamada ao banco de dados agora viaja por cinco serviços, duas filas e um service mesh. E mesmo assim, se um falha, tudo cai. Você não tem microsserviços: tem um monólito distribuído. E é a pior arquitetura possível.
O vídeo acima, do canal The Serious CTO, coloca o dedo numa ferida que na SISCON vemos toda vez que aterrissamos em um projeto de modernização: equipes que compraram o discurso dos microsserviços sem ter nem a escala, nem a organização, nem o músculo de plataforma para sustentá-los. O resultado não é um sistema mais ágil. É um mais caro, mais frágil e mais lento de mudar.
Microsserviços não são uma estratégia de escalabilidade. São uma estratégia de coordenação.
Esta é a confusão central do mercado. Microsserviços não nasceram para "escalar o seu tráfego" — um monólito bem feito aguenta ordens de magnitude mais carga do que a maioria das empresas jamais verá. Microsserviços nasceram na Amazon, na Netflix e no Spotify para resolver um problema de gente: como permitir que 200 equipes liberem software de forma independente sem se atropelarem.
Se a sua organização tem uma equipe de doze desenvolvedores, você não tem um problema de coordenação entre 200 equipes. Tem um problema de doze pessoas. E para doze pessoas, um monólito bem estruturado é objetivamente melhor: um único deploy, uma única transação, um único log, um único banco de dados. A complexidade operacional despenca.
O "imposto de coordenação" do qual ninguém avisou
Quando você divide um sistema em N serviços, não elimina a complexidade — move ela. Ela sai do seu código e entra na rede, na operação e nos processos da sua equipe. É o que alguns chamam de coordination tax, e quase sempre é subestimado no business case original:
- Cada nova feature toca vários repositórios. Uma história de usuário que antes era um PR vira quatro PRs coordenados, com dependências de ordem de merge.
- Seu CI/CD vira um sistema em si mesmo. Pipelines, registries, gestão de versões de contratos, ambientes de teste com N serviços no ar. Você precisa de uma equipe de plataforma dedicada.
- Debugging entre serviços é um esporte radical. Sem tracing distribuído bem implementado, encontrar onde uma transação quebrou pode levar dias.
- As transações distribuídas são um mito. O que você tinha como uma transação ACID vira um saga pattern com compensações, idempotência e estados inconsistentes que o negócio tem que aprender a tolerar.
- Sua conta de cloud dispara. Pesquisas da CNCF e relatórios públicos de empresas que migraram mostram consistentemente que os custos de infraestrutura sobem depois de adotar microsserviços — mais nós, mais networking, mais observabilidade, mais armazenamento.
Como se parece um "monólito distribuído" (e por que é o pior dos dois mundos)
O monólito distribuído é o que acontece quando você divide o código mas não divide os acoplamentos. Os sinais são brutais e quase sempre os mesmos:
- Para liberar uma feature você precisa implantar 3, 4 ou 5 serviços em uma ordem específica.
- Os serviços compartilham o mesmo banco de dados (ou pior: tabelas diferentes do mesmo esquema lógico).
- Uma queda no serviço "menos importante" derruba o resto porque alguém o invoca de forma síncrona no fluxo crítico.
- Os contratos entre serviços mudam sem versionamento, então uma mudança em um quebra os demais.
- Nenhuma equipe "é dona" de um serviço com clareza — todos editam tudo.
Se soa familiar, você não tem um problema de implementação. Tem um problema de arquitetura: aplicou o padrão errado ao tamanho errado de organização.
A pergunta honesta antes de fragmentar qualquer coisa
Antes de dividir um sistema, vale a pena responder a sério três perguntas — sem "porque está na moda" como resposta válida:
1. Qual é o problema de negócio real que isso resolve? Se a resposta é "queremos modernizar" ou "queremos estar na nuvem", não é razão suficiente. Razões legítimas: um módulo tem um ciclo de vida radicalmente diferente do resto (muda 10x mais rápido ou 10x menos), um módulo tem requisitos de escalabilidade ou conformidade muito distintos, ou há equipes fisicamente separadas que precisam operar de forma independente.
2. Temos o músculo de plataforma para sustentar isso? Microsserviços exigem observabilidade séria (logs, métricas e traces correlacionados), CI/CD maduro, um service mesh ou equivalente, gestão centralizada de segredos e políticas claras de versionamento de APIs. Se você não tem isso antes de começar, vai aprender a ter em produção — e vai doer.
3. Nossa estrutura organizacional combina com esta arquitetura? A Lei de Conway é implacável: você acaba construindo sistemas que refletem a comunicação da sua organização. Se tem uma única equipe de desenvolvimento, vai construir um monólito disfarçado. Se quer microsserviços de verdade, primeiro precisa de equipes de verdade com donos, OKRs e autonomia.
A alternativa que raramente é proposta: o monólito modular
Entre "tudo em um único blob de código" e "microsserviços desde o primeiro dia" existe um meio-termo onde vive a maioria dos sistemas bem-sucedidos: o monólito modular. É um único processo, um único deploy, um único banco de dados — mas internamente está dividido em módulos com fronteiras claras, sem que um módulo possa meter a mão nas entranhas do outro.
Vantagens: você fica com a simplicidade operacional de um monólito (um log, um deploy, transações ACID, debugging local), mas com a disciplina de limites internos que faz com que quando chegar o dia em que um módulo realmente precise viver à parte, você consiga extraí-lo com pouca dor. Empresas como a Shopify documentaram durante anos como essa arquitetura as levou muito longe antes de precisarem extrair serviços.
Quando fragmentar faz sentido de verdade?
Há cenários reais em que microsserviços são a resposta certa — não queremos cair no extremo oposto. Os mais comuns que vemos em projetos sérios:
- Um módulo precisa escalar de forma muito distinta do resto. Por exemplo, um motor de computação intensiva que precisa de GPUs versus uma camada web que precisa de muitas réplicas pequenas.
- Um módulo tem requisitos regulatórios ou de isolamento. Dados pessoais sensíveis, módulos sujeitos a auditorias independentes, segregação por país.
- Há uma equipe dedicada real com um domínio claramente delimitado. Não "uma equipe que toca quatro serviços", mas uma equipe dona de um bounded context completo.
- Você está fazendo strangler fig sobre um sistema legado. Aqui os "microsserviços" são uma tática de migração, não a arquitetura final.
A conclusão que não vende cursos mas constrói sistemas que duram
A arquitetura de software não é moda. É uma decisão que você vai viver por cinco a dez anos. Adotar microsserviços sem ter nem o problema, nem a escala, nem a equipe para sustentá-los garante uma coisa: pagar o custo completo da complexidade distribuída sem receber nenhum dos benefícios.
Se está começando um sistema novo, comece com um monólito modular bem desenhado. Se já tem um monólito que dói, não presuma que microsserviços são a resposta — primeiro entenda por que dói. Às vezes é arquitetura. Muitas vezes é disciplina, observabilidade ou processos. E se já está em um monólito distribuído, o melhor que pode fazer é ter a coragem de reconsolidar o que nunca deveria ter sido dividido.
Está avaliando dividir ou reconsolidar um sistema? Agende uma sessão de 30 min → · Conheça nossos serviços de desenvolvimento de software e manutenção e suporte.
Fonte do vídeo: "The Microservices Scam Nobody Talks About" — The Serious CTO. Ver no YouTube.