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)
