Monolito ou microsserviços: como escolher sem se arrepender
Publicado em 2026-09-12 por frfrand
Cinco preguntas que deciden mejor que cualquier diagrama, por qué la arquitectura correcta depende de tu equipo y no de tu tecnología, y cómo dejar la puerta abierta a cambiar.
A discussão sobre arquitetura costuma começar pela tecnologia e terminar mal. Escolhe-se o que está na moda, ou o que usa uma empresa que tem mil engenheiros, e depois se briga com as consequências por anos.
Cinco perguntas ordenam melhor a decisão, e nenhuma é técnica.
1. Quantas equipes implantam?
É a pergunta mais importante, porque o benefício central de separar serviços é que equipes diferentes publiquem sem se coordenar.
Uma equipe, uma implantação. Não é uma regra rígida, é uma observação do que funciona: o custo de coordenar implantações só existe se houver várias equipes se coordenando.
2. O que é lento de verdade?
É preciso medir, não supor.
Na maioria das vezes, o gargalo de um aplicativo web é uma consulta sem índice, a falta de cache ou uma chamada externa lenta. Nenhuma dessas três se resolve separando serviços; de fato, separar adiciona latência de rede por cima.
Se você nunca mediu, a arquitetura não é o seu problema ainda.
3. Quem o opera às três da manhã?
A complexidade tem um custo que se paga de plantão.
Dez serviços são dez coisas que podem falhar, dez conjuntos de logs para correlacionar e dez implantações para reverter. Se a equipe é pequena, esse custo é pago por uma pessoa, e é pago à noite.
É uma consideração legítima e quase nunca aparece nos diagramas.
4. Há uma parte que escala de forma diferente?
Se o processamento de vídeo consome vinte vezes mais que o restante e cresce separadamente, há um argumento real para separá-lo.
A palavra-chave é medido. "Isso provavelmente vai crescer" não chega: quase nunca cresce como esperado.
5. Pode ser desfeito?
A melhor arquitetura é aquela que não te prende.
E aqui há uma assimetria que vale a pena conhecer: extrair um serviço de um monolito bem modularizado é trabalho; voltar a juntar serviços distribuídos é muito pior.
Por isso, em caso de dúvida, o caminho menos arriscado é começar junto.
A ordem que funciona
Monolito modular primeiro. Um deploy, uma base, e dentro módulos com fronteiras claras: cada um com sua interface, sem acessar as tabelas dos outros pelas costas.
Essa disciplina interna é o que torna possível tudo o resto. Um monolito sem fronteiras internas sim é um problema, e é o que deu má fama à palavra.
Medir onde dói. Com dados, não com intuição.
Extrair um serviço, com uma razão concreta. Um. Não o sistema inteiro.
O que quase sempre é a resposta correta
Para uma equipe de menos de dez pessoas: monolito modular, implantado de forma automática, com bons logs e métricas.
Isso não é conservadorismo: é que o principal benefício dos microsserviços (independência entre equipes) não existe quando há apenas uma equipe, e os custos existem igualmente.
No ArduMaker isso se traduz em algo prático: você pode ter um monolito implantado a partir de um repositório, e no dia em que extrair um serviço, implantá-lo no mesmo VPS ou em outro, com túneis entre eles em vez de expô-los. A arquitetura pode evoluir sem recriar a infraestrutura.
