Monólito: Quando Ainda Faz Sentido?

O que é monólito

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

Um sistema monolítico 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 monólito 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 monólito ficou com uma reputação injustamente negativa nos últimos anos, mas gigantes como Stack Overflow, Shopify e Basecamp continuam rodando monólitos em produção com alto desempenho.

Monólito vs microservicos

A escolha certa depende do tamanho do time, da complexidade do domínio e da maturidade operacional.

A decisão entre monólito e microservicos não e técnica, e organizacional. Microservicos fazem sentido quando o time e grande o suficiente para ter equipes por domínio, 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 domínios ainda mal definidos, o monólito 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 monólito e migre para microservicos apenas quando o monólito se tornar um obstáculo real.

Monólito modular

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

O monólito modular e uma arquitetura que busca o melhor dos dois mundos: a simplicidade operacional do monólito com a separação de responsabilidades dos microservicos. Em vez de ter um código espaguete onde qualquer classe pode acessar qualquer outra, o monólito 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 monólito modular em escala.

Casos de sucesso com monólito

Amazon Prime Vídeo, Shopify e Stack Overflow mostram que monólito funciona em escala.

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

Quando o monólito e a escolha certa

Para times pequenos, domínios novos e sistemas em fase inicial, o monólito acelera a entrega.

O monólito faz mais sentido quando: o time tem menos de 10 desenvolvedores; o domínio 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 monólito quase sempre e a escolha mais pragmática e eficiente.

Sinais de que e hora de migrar

Quando o monólito começa a atrasar o time, e hora de considerar a migração.

Alguns sinais indicam que o monólito 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 mudanças 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 monólito bem

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

Um monólito 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 monólito bem organizado e muito mais fácil de migrar para microservicos quando chegar o momento certo.

Vantagens do monólito

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

As vantagens do monólito 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 monólito 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 monólito

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

O principal risco do monólito 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 mudança em qualquer lugar pode quebrar qualquer coisa. A prevenção e a mesma do monólito 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 mudança 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

Monólito bem organizado e uma arquitetura solida e muitas vezes a escolha mais inteligente.

O monólito 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 monólito modular, oferece separação de responsabilidades sem os custos operacionais dos sistemas distribuídos. Os casos de Amazon Prime Vídeo, Shopify e Stack Overflow mostram que monólitos funcionam em escala. A regra e simples: comece com o monólito, organize bem com limites explicitos entre módulos, e migre para microservicos apenas quando o monólito se tornar um obstáculo real e mensurável para o time.

Tutoriais em Video

David Heinemeier Hansson: Microservices vs. Monolith

Modular Monoliths, Simon Brown, GOTO 2018

Don't Build a Distributed Monolith, NDC London 2023

Mini Course: Modular Monolith

Serverless was a big mistake... says Amazon

When To Use Microservices (And When Not To!), GOTO 2020