Microsserviços ou monolito: quando cada arquitetura compensa

Microsserviços compensam quando autonomia de equipes, escala seletiva e entregas independentes resolvem problemas reais. Sem essas pressões, um monolito bem modularizado costuma ser mais simples de desenvolver, mais barato de operar e mais rápido de mudar.

A decisão vale tanto para quem está começando um produto quanto para quem já tem um sistema em produção e sente que ele virou gargalo. Abaixo estão os critérios que usamos para decidir, os custos que costumam ficar fora da conta e o caminho para migrar sem transformar a arquitetura em aposta.

O que muda entre um monolito e microsserviços

Um monolito reúne regras de negócio, acesso a dados e interfaces em uma única aplicação, com um único deploy. Um monolito modular mantém esse deploy único, mas organiza o código em módulos com responsabilidades e interfaces explícitas: pagamentos, catálogo, usuários, cada um com sua fronteira.

Microsserviços dividem a aplicação em serviços que podem ser implantados separadamente, cada um responsável por um domínio de negócio e, idealmente, dono dos próprios dados. A coordenação que antes acontecia dentro de um processo passa a acontecer pela rede, via APIs ou eventos.

Um exemplo deixa a diferença concreta. Pense no fluxo de um pedido: criação, pagamento, reserva de estoque e envio.

• No monolito, as etapas rodam no mesmo processo e podem compartilhar uma transação de banco. Se a reserva de estoque falha, a transação é revertida e o pedido volta ao estado anterior. Qualquer mudança, porém, exige publicar a aplicação inteira.
• Com microsserviços, cada etapa vive em um serviço com banco próprio. Não existe transação global. A consistência depende de padrões como Saga, em que cada serviço executa uma ação de compensação quando um passo seguinte falha. Em troca, dá para escalar o pagamento em um pico sem mexer no estoque.

Nenhum dos dois modelos garante qualidade por definição. Um monolito pode ser bem organizado. O que cria problema é deixar qualquer mudança atravessar fronteiras mal definidas. Do mesmo jeito, ter muitos serviços implantáveis não significa ter desacoplamento. A pesquisa sobre dívida arquitetural em microsserviços apontou bancos compartilhados e APIs mal projetadas como fontes relevantes de dependência: mudanças de esquema quebram serviços e contratos ruins acoplam times [1]. Para quem contrata software, a consequência é direta. Dividir a aplicação sem dividir as responsabilidades eleva o custo e não entrega autonomia.

Quando microsserviços compensam

Microsserviços fazem sentido quando existem domínios relativamente estáveis, ritmos de mudança diferentes e necessidade concreta de implantação independente. Os sinais mais comuns aparecem em três frentes.

Autonomia de equipes

A Lei de Conway resume bem o ponto: a arquitetura de um sistema tende a espelhar a estrutura de comunicação da organização. Quando vários times cuidam de áreas distintas do produto e um precisa esperar o deploy do outro para publicar, a separação em serviços remove uma fila real.

Essa vantagem tem pré-requisitos: contratos de API estáveis e versionados, propriedade clara dos dados, observabilidade e automação de entrega. A literatura descreve microsserviços como subsistemas fracamente acoplados que podem ser desenvolvidos, implantados e escalados de forma independente, e também aponta a decomposição como uma decisão difícil, com efeitos sobre desenvolvimento, operação e manutenção [2]. Independência é resultado do desenho e das práticas de engenharia. A quantidade de serviços, sozinha, não a produz.

Escala seletiva

Quando um componente concentra a carga, isolá-lo permite escalar só o que precisa. Um motor de cálculo intensivo ou um checkout que recebe picos em campanhas são exemplos típicos. Se a carga se distribui de forma parecida por toda a aplicação, o ganho é pequeno e o custo de orquestração tende a superar o benefício.

Requisitos técnicos divergentes

Algumas partes do sistema pedem isolamento de falhas, ciclo de entrega próprio, outra linguagem ou execução perto da origem dos dados. Em aplicações de Internet das Coisas, por exemplo, uma arquitetura distribuída entre borda, fog e nuvem foi estudada justamente para orquestrar microsserviços quando cargas e localização dos dispositivos variam [3]. Isso não torna microsserviços obrigatórios em todo sistema conectado. Mostra que a distribuição pode atender a uma necessidade física da aplicação, além de uma preferência arquitetural.

Dados com exigências próprias de governança também entram aqui. Separar uma base sensível em um serviço com acesso restrito pode simplificar auditoria e controles de LGPD, desde que a separação seja real e outros serviços não leiam essas tabelas por fora.

Quando o monolito continua sendo a escolha certa

O monolito costuma ser a escolha mais prudente quando a principal incerteza está no produto. No começo, as fronteiras de domínio mudam conforme usuários, regras e processos são compreendidos. Manter os módulos no mesmo repositório e no mesmo processo facilita refatorações que cruzam essas fronteiras, sem versionar contratos, sem compatibilidade entre deploys e sem coordenar dados distribuídos.

Para startups em validação, esse argumento pesa ainda mais. O objetivo da fase é aprender rápido com pouco capital. Investir em uma arquitetura "à prova de futuro" antes de saber se o produto tem tração gera dívida técnica e custo fixo sem retorno. Se você está nessa fase, o escopo pesa mais que a arquitetura, e vale ler como definir o escopo de um MVP sem desperdiçar dinheiro.

Uma equipe pequena também ganha pouco com autonomia de deploy por serviço. Se as mesmas pessoas mantêm o sistema inteiro, a divisão cria mais pipelines, logs, alertas, configurações e pontos de falha, e as dependências organizacionais continuam lá. O monolito reduz essa superfície e libera esforço para testes, modularidade, segurança e entrega.

A granularidade merece atenção à parte, porque serviços menores não são automaticamente melhores. Uma revisão da literatura tratou a definição da granularidade ideal como problema de pesquisa ainda aberto. Os estudos analisados olhavam sobretudo para escalabilidade, desempenho e consumo de recursos, e davam menos atenção a manutenibilidade [4]. Métricas de infraestrutura não bastam. A divisão precisa melhorar propriedade, capacidade de mudança e entendimento do sistema.

O custo que costuma ficar fora da conta

Microsserviços trazem uma camada de infraestrutura e de trabalho que não existe no monolito. Antes de decidir, coloque cada item na estimativa:

• API Gateway: centraliza autenticação, roteamento e limites de requisição.
• Comunicação entre serviços: retries, timeouts e circuit breaker, via service mesh ou biblioteca de cliente.
• Mensageria assíncrona: um broker para eventos e para padrões como Saga.
• Observabilidade distribuída: logs centralizados, métricas e rastreamento que siga uma requisição por vários serviços.
• Orquestração: em geral contêineres e Kubernetes, com o custo de operar o cluster. Tratamos as escolhas dessa camada em arquitetura com Kubernetes para líderes de engenharia.
• Pipelines independentes: um CI/CD por serviço, com testes de contrato.
• Pessoas: alguém precisa operar tudo isso. Em ambientes distribuídos, a função de DevOps ou SRE deixa de ser opcional.
• Governança de contratos: versionamento de APIs e de esquemas de eventos. Sem isso, cada sprint quebra uma integração.

Do lado do monolito, o custo aparece de outra forma: quando um deploy único cria fila entre equipes, quando módulos não conseguem evoluir separados ou quando a aplicação inteira precisa escalar por causa de uma carga localizada. A comparação justa coloca os dois custos lado a lado, com números do seu contexto.

A armadilha do monolito distribuído

O pior resultado possível junta as desvantagens dos dois modelos. Um monolito distribuído nasce quando a equipe separa o código em serviços, mas mantém um banco compartilhado, depende de chamadas síncronas em cadeia ou precisa publicar vários serviços juntos para qualquer mudança.

O time passa a pagar o custo de operar um ambiente distribuído e continua com o acoplamento forte. Latência de rede e falhas parciais geram bugs difíceis de rastrear, e o tempo para resolver incidentes cresce.

Três sinais indicam que você está nesse cenário:

1. Dois ou mais serviços leem e escrevem nas mesmas tabelas.
2. Uma funcionalidade simples exige deploy coordenado de vários serviços.
3. Uma falha em um serviço derruba uma cadeia inteira de chamadas.

Uma forma de evitar é o chamado padrão Citadel: manter o núcleo como monolito modular e extrair apenas as cargas que realmente se beneficiam de viver fora dele, como processamento intensivo de eventos ou modelos de machine learning. Poucos serviços satélites, bem justificados, em volta de um núcleo coeso.

Como fazer um monolito aguentar crescimento

Monolito não significa limite baixo de escala. Com boas práticas, ele atende volumes altos com operação simples:

• Módulos bem delimitados: pacotes por domínio, com Domain-Driven Design, e regras que proíbem um módulo de acessar as tabelas de outro. Isso também prepara uma extração futura.
• CI/CD robusto: build, testes unitários e de integração automáticos a cada mudança, e deploy com estratégias como blue/green ou canary.
• Infraestrutura elástica: várias instâncias do monolito atrás de um balanceador, com autoscaling. Serviços gerenciados de contêiner, como AWS Fargate ou Google Cloud Run, simplificam essa parte.
• Observabilidade desde o início: logs estruturados, métricas de latência e alertas de erro. Padrões abertos como OpenTelemetry evitam amarrar o produto a um fornecedor.
• Feature flags: liberar funcionalidades de forma controlada reduz o risco de cada deploy.

Antes de concluir que o monolito chegou ao limite, faça um teste de carga com o volume esperado. Muitas vezes o gargalo está em uma consulta, um índice ou um cache, e não na arquitetura.

Como decidir sem transformar a migração em aposta

A decisão compara o problema atual com o custo completo da alternativa. Algumas perguntas objetivas ajudam:

• Os domínios mudam em ritmos diferentes? Se sim, a independência de deploy traz ganho real.
• A carga se concentra em poucos componentes? Se sim, a escala seletiva pode pagar a conta.
• Existe cultura de DevOps? Sem automação de deploy e monitoramento, a complexidade distribuída paralisa o time.
• Os bloqueios entre equipes são recorrentes e mensuráveis? Sem evidência, a separação resolve um problema que ainda não existe.
• As fronteiras de domínio estão estáveis? Se ainda mudam a cada trimestre, separar agora congela decisões erradas.

Migrar para microsserviços é uma transformação técnica e organizacional. Uma pesquisa qualitativa baseada em entrevistas descreveu essas migrações como complexas, prolongadas e multifacetadas, com mudanças na estrutura da organização e no trabalho de engenharia [5]. Por isso a extração gradual tende a ser mais controlável:

1. Identifique uma fronteira que já causa atrito.
2. Defina quem é dono dos dados dessa fronteira.
3. Extraia esse único serviço, com observabilidade e caminho de volta.
4. Meça se a separação reduziu dependências e tempo de entrega.
5. Só então avalie a próxima extração.

O restante pode continuar no monolito modular. Uma arquitetura híbrida é um ponto de chegada legítimo. Para comparar com outros estilos, como orientação a eventos ou arquitetura em camadas, veja como escolher o padrão de arquitetura de software ideal. E se a pressão por migrar vem de um código difícil de mudar, o problema pode ser dívida técnica acumulada, que se resolve sem trocar de arquitetura.

Na experiência da Phurshell, em 11 anos de mercado e mais de 100 produtos digitais entregues, a pergunta mais produtiva costuma ser "qual dependência impede o negócio de avançar?". A resposta pode apontar para microsserviços, para a correção das fronteiras de um monolito ou para uma arquitetura híbrida. É esse tipo de diagnóstico que fazemos no trabalho de engenharia e arquitetura de software.

Perguntas frequentes

Startup deve começar com microsserviços?

Na maioria dos casos, não. Na fase de validação, o produto muda rápido e as fronteiras de domínio ainda não estão claras. Um monolito modular entrega mais rápido, custa menos para operar e permite extrair serviços depois, quando houver evidência de necessidade. Se a dúvida é de orçamento e prazo do produto como um todo, a calculadora de custo dá uma faixa inicial.

Um monolito escala?

Escala. Várias instâncias da mesma aplicação atrás de um balanceador, com autoscaling, cache e banco bem indexado, atendem volumes altos. O limite costuma aparecer quando uma parte específica tem carga muito diferente do resto ou quando várias equipes disputam o mesmo deploy.

O que é monolito distribuído?

É um sistema dividido em serviços que continuam acoplados: compartilham banco, dependem de chamadas síncronas em cadeia ou precisam ser publicados juntos. Reúne o custo operacional de microsserviços com a rigidez de um monolito mal organizado.

Quanto custa migrar para microsserviços?

Depende do tamanho do sistema, da qualidade das fronteiras atuais e da maturidade de DevOps da equipe. Além do desenvolvimento, entram na conta gateway, mensageria, observabilidade, orquestração, pipelines por serviço e pessoas para operar. Extrair um serviço por vez permite medir o custo real antes de continuar.

Dá para voltar de microsserviços para monolito?

Dá, e algumas empresas fazem isso quando a fragmentação não trouxe autonomia. Consolidar serviços que sempre mudam juntos em um único módulo costuma reduzir custo e incidentes.

Referências

1. Saulo Soares de Toledo, Antonio Martini, Dag I. K. Sjøberg (2021). Identifying architectural technical debt, principal, and interest in microservices: A multiple-case study. doi:10.1016/j.jss.2021.110968
2. Giovanni Quattrocchi, Davide Cocco, Simone Staffa et al. (2024). Cromlech: Semi-Automated Monolith Decomposition Into Microservices. doi:10.1109/tsc.2024.3354457
3. Salman Taherizadeh, Vlado Stankovski, Marko Grobelnik (2018). A Capillary Computing Architecture for Dynamic Internet of Things: Orchestration of Microservices from Edge Devices to Fog and Cloud Providers. doi:10.3390/s18092938
4. Fredy Humberto Vera-Rivera, Carlos Mauricio Gaona-Cuevas, Hernán Astudillo (2021). Defining and measuring microservice granularity: a literature overview. doi:10.7717/peerj-cs.695
5. Hamdy Michael Ayas, Philipp Leitner, Regina Hebig (2023). An empirical study of the systemic and technical migration towards microservices. doi:10.1007/s10664-023-10308-9

Conclusão

Microsserviços compensam quando autonomia de equipes, implantação independente, isolamento de falhas ou escala seletiva geram valor suficiente para pagar a complexidade distribuída. O monolito continua certo quando o domínio ainda está sendo descoberto, a equipe atua como uma unidade e o deploy conjunto não trava o negócio. Entre os extremos, um monolito modular com extrações graduais preserva a simplicidade sem bloquear a evolução. Revise a decisão quando surgirem evidências concretas, como bloqueios recorrentes entre times, cargas muito diferentes ou fronteiras de domínio estáveis.

Está avaliando uma arquitetura nova ou uma migração? Converse com a Phurshell e valide as premissas antes de comprometer o orçamento.