Monolito: Quando Ainda Faz Sentido

O que e monolito

Um monolito e um sistema onde todo o código roda em um único processo.

Um sistema monolitico e aquele onde todos os módulos, funcionalidades e camadas rodam dentro de um único processo deployável. Quando você faz build e deploy, toda a aplicação vai junto. Isso não e necessariamente ruim. Para a maioria dos sistemas em fase inicial, o monolito e a escolha mais inteligente: mais simples de desenvolver, testar, debugar e fazer deploy. A complexidade de um sistema distribuído só faz sentido quando o tamanho do time ou a escala do sistema realmente exige. O monolito ficou com uma reputação injustamente negativa nos últimos anos, mas gigantes como Stack Overflow, Shopify e Basecamp continuam rodando monolitos em produção com alto desempenho.

Monolito vs microservicos

A escolha certa depende do tamanho do time, da complexidade do dominio e da maturidade operacional.

A decisão entre monolito e microservicos não e técnica, e organizacional. Microservicos fazem sentido quando o time e grande o suficiente para ter equipes por dominio, quando partes do sistema precisam escalar de forma completamente diferente, e quando o time ja tem maturidade operacional para lidar com sistemas distribuídos. Para times pequenos, startups e sistemas com dominios ainda mal definidos, o monolito permite mais velocidade de entrega. Não existe resposta certa universal. O que existe e o contexto certo para cada escolha. A regra de Martin Fowler e clara: comece com o monolito e migre para microservicos apenas quando o monolito se tornar um obstaculo real.

Monolito modular

O monolito modular tem separação interna clara de módulos, mas roda em um único processo.

O monolito modular e uma arquitetura que busca o melhor dos dois mundos: a simplicidade operacional do monolito com a separação de responsabilidades dos microservicos. Em vez de ter um código espaguete onde qualquer classe pode acessar qualquer outra, o monolito modular estabelece limites explicitos entre módulos. Cada módulo tem sua própria pasta, suas próprias interfaces públicas e suas próprias dependências internas. A comunicação entre módulos e feita apenas pelas interfaces definidas, nunca por acesso direto a internals. O banco pode ser compartilhado, mas cada módulo tem seu próprio schema ou conjunto de tabelas. Shopify e um dos exemplos mais famosos de monolito modular em escala.

Casos de sucesso com monolito

Amazon Prime Video, Shopify e Stack Overflow mostram que monolito funciona em escala.

Em 2023, a Amazon Prime Video publicou um estudo de caso onde voltou de uma arquitetura de microservicos serverless para um monolito e reduziu os custos operacionais em 90%. O sistema de monitoramento de áudio e video foi mais simples, mais barato e mais eficiente como monolito. Stack Overflow atende bilhões de requisições por mes com uma arquitetura essencialmente monolitica rodando em poucos servidores de alta performance. Shopify cresceu para ser uma das maiores plataformas de e-commerce do mundo como um monolito Ruby on Rails. Esses casos mostram que monolito não e sinonimo de sistema legado ou mal projetado.

Quando o monolito e a escolha certa

Para times pequenos, dominios novos e sistemas em fase inicial, o monolito acelera a entrega.

O monolito faz mais sentido quando: o time tem menos de 10 desenvolvedores; o dominio ainda esta sendo descoberto e as fronteiras não estão claras; a velocidade de entrega e mais importante que a escalabilidade granular; o sistema não tem partes com demandas de escala radicalmente diferentes; e o time não tem maturidade operacional para lidar com sistemas distribuídos. Também faz sentido quando a consistência de dados e crítica e transações distribuídas seriam muito complexas. Para sistemas internos, ferramentas de backoffice e MVPs, o monolito quase sempre e a escolha mais pragmatica e eficiente.

Sinais de que e hora de migrar

Quando o monolito começa a atrasar o time, e hora de considerar a migração.

Alguns sinais indicam que o monolito esta se tornando um problema: o ciclo de build e deploy ficou tao lento que paralisa o time; diferentes partes do sistema precisam escalar de forma radicalmente diferente e isso esta custando caro; equipes diferentes ficam bloqueadas esperando umas as outras para fazer deploy; pequenas mudancas em um módulo geram bugs em módulos completamente diferentes; e a base de código ficou tao grande que ninguem mais entende o sistema inteiro. Esses sinais devem aparecer na prática, não ser antecipados como desculpa para adotar microservicos prematuramente.

Como organizar um monolito bem

Separação por módulo de negócio, interfaces explicitas e testes solidos previnem o big ball of mud.

Um monolito bem organizado não e um amontoado de código sem estrutura. Ele tem separação clara por módulo de negócio, com cada módulo tendo suas próprias classes, interfaces e testes. A regra de ouro e que um módulo só possa acessar outro pelas interfaces públicas definidas, nunca pelos internals. Isso pode ser enforced por ferramentas como ArchUnit no Java ou pelo prorio compilador em linguagens com módulos explicitamente declarados. Testes de arquitetura automatizados ajudam a garantir que as regras de dependência não sejam violadas ao longo do tempo. Um monolito bem organizado e muito mais fácil de migrar para microservicos quando chegar o momento certo.

Vantagens do monolito

Simplicidade operacional, transações ACID e debugging direto são as grandes vantagens.

As vantagens do monolito são concretas: um único processo para buildar, testar e deployar; transações ACID nativas sem precisar de padrões como Saga; debugging simples com um único stack trace; sem overhead de comunicação de rede entre módulos; sem necessidade de service discovery, tracing distribuído ou orquestração de containers; e menor custo de infraestrutura. Para times pequenos, a diferença de produtividade entre um monolito bem organizado e um conjunto de microservicos pode ser enorme. O investimento em infraestrutura distribuída só compensa quando o sistema realmente precisar.

Cuidados com o monolito

Sem organização, o monolito vira um big ball of mud impossível de manter.

O principal risco do monolito e o acoplamento crescente sem disciplina. Quando qualquer classe pode chamar qualquer outra, o sistema vai gradualmente se tornando uma bola de lama onde uma mudanca em qualquer lugar pode quebrar qualquer coisa. A prevenção e a mesma do monolito modular: limites explicitos entre módulos, interfaces públicas definidas, e testes que validam as dependências. Outro cuidado e o deploy atômico: uma mudanca em qualquer parte exige um novo deploy de tudo. Para sistemas com alta frequência de deploy, isso pode ser um gargalo. A solução não e necessariamente microservicos, mas sim melhorar o pipeline de CI/CD.

Resumo

Monolito bem organizado e uma arquitetura solida e muitas vezes a escolha mais inteligente.

O monolito não e uma arquitetura obsoleta. E uma escolha arquitetural valida com vantagens reais: simplicidade operacional, transações ACID, debugging direto e menor custo de infraestrutura. Quando bem organizado como monolito modular, oferece separação de responsabilidades sem os custos operacionais dos sistemas distribuídos. Os casos de Amazon Prime Video, Shopify e Stack Overflow mostram que monolitos funcionam em escala. A regra e simples: comece com o monolito, organize bem com limites explicitos entre módulos, e migre para microservicos apenas quando o monolito se tornar um obstaculo real e mensurável para o time.