O que são microsserviços e por que surgiram
Publicado em 2026-09-12 por frfrand
No nacieron por una razón técnica sino organizativa. Qué problema resuelven de verdad, qué costos traen y por qué el monolito modular es la respuesta correcta para la mayoría.
Um microsserviço é um serviço pequeno, implantável de forma independente, responsável por uma capacidade de negócio, que se comunica com os outros pela rede.
Essa é a definição. O interessante é de onde veio a ideia, porque explica quando faz sentido.
Não nasceu por uma razão técnica
As empresas que popularizaram essa abordagem não tinham um problema de desempenho. Tinham um problema de organização.
Quando duzentas pessoas trabalham sobre o mesmo código e o mesmo implante, aparece um gargalo que não é técnico: cada mudança precisa ser coordenada, cada publicação afeta a todos, e a velocidade de todos fica limitada pela equipe mais lenta.
Os microsserviços atacam isso: se cada equipe tem seu serviço, sua base e seu implante, cada uma avança no seu ritmo.
Daí sai a regra mais útil para decidir: se toda a sua aplicação é feita por uma única equipe, você está pagando os custos sem receber o benefício principal.
O que realmente aportam no técnico
Escalar por partes. Se o processamento de imagens consome muito e o resto não, escala só essa parte. Em um monolito, escala tudo junto.
Isolar falhas. Um serviço que cai não precisa levar os outros com ele, se o sistema estiver projetado para tolerá-lo. Sem essa parte, na verdade você multiplicou os pontos de falha.
Tecnologias distintas. Um serviço de cálculo intensivo em uma linguagem compilada, o resto em outra. Útil às vezes, e uma fonte enorme de complexidade se for abusado.
O que custam, desde o primeiro dia
Aqui convém ser muito honesto, porque esses custos aparecem mesmo em sistemas pequenos.
A rede entre cada chamada. O que era uma chamada de função passa a ser uma requisição HTTP: latência, serialização e a possibilidade de falhar. Todo o código de retentativas, tempos de espera e circuit breakers que antes não existia, agora é seu.
As transações. Em um banco, envolver várias operações em uma transação é trivial. Distribuído entre três serviços com três bancos, isso desaparece. É preciso implementar consistência eventual e compensações, o que é muito mais difícil do que parece.
A depuração. Um erro que atravessa cinco serviços está em cinco logs diferentes. Sem rastreamento distribuído (que precisa ser montado e mantido), reconstruir o que aconteceu é muito custoso.
A operação. Dez serviços são dez implantações, dez configurações, dez conjuntos de métricas e alertas.
O monolito modular
Entre os dois extremos, há uma opção que costuma ser a correta e é pouco mencionada: um monolito bem modularizado.
Uma única implantação, um único banco, e dentro módulos com fronteiras claras: cada um com sua interface, sem acessar as tabelas dos outros pelas costas.
Ele traz quase todos os benefícios de organização de código sem nenhum dos custos da rede. E se algum dia um módulo precisar se separar de verdade, a fronteira já está traçada, então extraí-lo é viável.
O caminho que funciona é esse: começar com um monolito modular e extrair um serviço quando surgir um motivo concreto e mensurável. Não o contrário.
A pergunta que ordena a decisão
Não é "qual arquitetura é melhor?", mas "qual é o meu gargalo real?".
Se vários times se pisam ao implantar, os microsserviços resolvem.
Se uma consulta não tem índice, ou falta cache, ou o servidor está com pouca memória, os microsserviços não resolvem nada e somam trabalho permanente.