Em uma entrevista para uma vaga de Engenheiro de Software, fui questionado sobre quando usar microsserviços e quando não usar. Minha resposta foi muito vaga e percebi que não convenci o entrevistador. Por isso, resolvi pesquisar mais a fundo sobre essa questão. Li sobre os dilemas de Martin Fowler e Stefan Tilkov, além de outras referências, e percebi que a resposta nem sempre é simples. Já participei de dois projetos que usavam microsserviços e, em ambos, a decisão já havia sido tomada antes da minha chegada.

Ainda não vivi a experiência de tomar a decisão de qual arquitetura é mais apropriada para um projeto do zero, mas espero estar preparado quando a oportunidade surgir.

Recentemente, li dois textos que discutem o dilema arquitetural entre iniciar o desenvolvimento de um novo sistema de software como um monólito ou adotar diretamente uma arquitetura de microsserviços. Martin Fowler defende a estratégia de começar com um monólito, argumentando que isso evita complexidade inicial desnecessária e permite compreender melhor os limites dos domínios antes de fragmentar o código. Em contrapartida, Stefan Tilkov contesta essa visão, afirmando que iniciar com componentes separados é mais eficaz, pois os monólitos tendem a gerar um acoplamento excessivo que dificulta futuras divisões. Enquanto Fowler enfatiza que a maioria dos casos de sucesso com microsserviços surgiu de monólitos que cresceram organicamente, Tilkov acredita que planejar subsistemas independentes desde o início previne conexões problemáticas que são difíceis de desfazer depois. Ambas as fontes reconhecem que a experiência da equipe, a complexidade do sistema e o conhecimento do domínio são fatores cruciais para definir qual abordagem adotar em cada projeto específico.

Na minha primeira experiência com microsserviços, os serviços eram isolados e não havia comunicação direta entre eles. Já na segunda, essa comunicação era fundamental para o funcionamento da arquitetura. Nesse período, pude vivenciar na prática as preocupações documentadas na literatura sobre microsserviços, especialmente a importância do uso rigoroso de padrões e boas práticas.

Quando usar a Arquitetura Monolítica (e a estratégia Monolith First)
O monólito é a opção mais oportuna quando a prioridade inicial é a velocidade de desenvolvimento, a simplicidade operacional e a rápida validação do produto.

Startups e Validação de Novos Produtos (Greenfield): Quando um produto está no início, a prioridade máxima é testar hipóteses com os usuários e acelerar o ciclo de feedback (aplicando o princípio YAGNI). Optar por microsserviços logo no início adiciona o atraso do chamado Microservice Premium (o custo operacional de gerenciar múltiplos serviços) antes mesmo de saber se o produto é viável no mercado.
Fronteiras de Domínio (Bounded Contexts) Incertas: Martin Fowler aponta que identificar os limites exatos entre os serviços é um grande desafio até para arquitetos experientes. Refatorar módulos dentro de um monólito é simples; mover funcionalidades entre microsserviços distribuídos exige um esforço imenso.
Equipes Enxutas ou sem Maturidade DevOps: Monólitos possuem um ciclo de desenvolvimento, teste, depuração e implantação muito mais simples e integrado. Operar microsserviços exige conhecimentos consolidados em infraestrutura de nuvem, conteinerização, automação de CI/CD e monitoramento de sistemas distribuídos.
Estratégia Monolith First (Martin Fowler): Consiste em iniciar com um monólito bem estruturado em módulos internos para compreender a complexidade do sistema e descobrir suas fronteiras reais. Conforme a aplicação cresce, extraem-se microsserviços gradualmente nas bordas ou reescreve-se o sistema aproveitando o aprendizado acumulado (Sacrificial Architecture).

Quando usar a Arquitetura de Microsserviços (e a visão Don't Start with a Monolith)
A arquitetura de microsserviços torna-se oportuna quando a aplicação atinge alta escala, grande complexidade de domínio e necessita de autonomia para múltiplos times.

Domínio Maduro e Bem Compreendido: Stefan Tilkov argumenta que, se a meta final do projeto é ter microsserviços e o domínio já é profundamente conhecido (como na reescrita ou segunda versão de um sistema), começar com um monólito pode ser um erro. No monólito, os componentes tendem a criar acoplamentos fortes no banco de dados, em bibliotecas compartilhadas e em chamadas de memória, tornando a separação posterior extremamente difícil ou quase impossível.
Paralelismo entre Múltiplas Equipes: O benefício fundamental dos microsserviços é criar limites rígidos que permitem que equipes separadas desenvolvam, testem e façam deploys de forma autônoma, sem interferir nos fluxos das demais.
Escalabilidade Granular e Resiliência: Quando serviços específicos sofrem altas variações de carga (como módulos de busca, recomendações ou pagamentos em plataformas como Netflix e Mercado Livre), é possível alocar recursos apenas para o serviço demandado, em vez de escalar todo o sistema. Além disso, se um microsserviço falhar, os demais continuam operando, evitando um ponto único de falha (Single Point of Failure).
Flexibilidade Tecnológica e Ciclos de Deploy Rápidos: Cada serviço pode adotar linguagens, frameworks e bancos de dados mais adequados para a sua tarefa específica, além de permitir atualizações frequentes sem a necessidade de retestar a aplicação inteira.

E você, já precisou tomar essa decisão? Poderia compartilhar os detalhes?

Fontes:

https://martinfowler.com/articles/dont-start-monolith.html

https://martinfowler.com/bliki/MonolithFirst.html

https://aws.amazon.com/pt/compare/the-difference-between-monolithic-and-microservices-architecture/

https://www.ibm.com/br-pt/think/topics/monolithic-vs-microservices

https://dev.to/alexnicolascode/monolito-vs-microsservicos-quando-usar-cada-arquitetura-o0n

https://www.rocketseat.com.br/blog/artigos/post/monolito-vs-microservices-como-escolher-arquitetura

  • Imagem criada com auxílio de Inteligência Artificial (Gemini / Imagen 3)