Blog/Artigos · Engenharia
O pêndulo do mercado, o imposto do sistema distribuído, o monólito modular como meio-termo e quando dividir de verdade compensa.
Antes de Babel, conta o Gênesis, toda a terra tinha uma só língua e as mesmas palavras, e por isso o que se propunham a fazer, faziam. A unidade dava poder de coordenação: um só entendimento, uma só voz. Depois vem o espalhamento, a divisão em muitas línguas, e a coordenação fica cara, porque cada grupo passa a falar o seu. É a tensão exata entre monólito e microsserviços. O monólito é a safah echat: uma base, uma língua, tudo junto, coordenação trivial e implantação única. Microsserviços são o espalhamento: muitos serviços autônomos, cada um com sua vida, ganhando independência ao preço de a coordenação entre eles virar um problema de sistema distribuído. Nenhum é certo por si; o que muda é o que cada escolha cobra e entrega.
A indústria viveu um pêndulo. Nos anos 2010, microsserviços viraram a resposta para tudo, embalados pelo exemplo de Netflix e Amazon, e times de todos os tamanhos passaram a quebrar sistemas em dezenas de serviços, muitas vezes cedo demais. Na virada da década, veio a ressaca: relatos de empresas que se afogaram na complexidade distribuída, e algumas que reverteram para o monólito e melhoraram desempenho e custo. O pêndulo voltou, e o consenso maduro que emergiu não é monólito nem microsserviços por dogma, é o monólito modular como padrão inicial e a divisão em serviços como decisão deliberada, quando justificada.
A raiz da confusão foi tratar uma decisão de trade-off como uma escolha de moda. Microsserviços não são uma versão mais avançada do monólito; são uma arquitetura diferente, com benefícios e custos diferentes, adequada a certos contextos e ruinosa em outros. Sam Newman, uma das vozes de referência do tema, é claro: comece com o monólito, e só divida quando tiver uma razão concreta e sentir a dor que a divisão resolve. A safah echat, uma só língua, é o ponto de partida sensato; o espalhamento é uma escolha que se faz quando a unidade começa a atrapalhar mais do que ajuda, não porque está na moda espalhar.
| Aspecto | Monólito | Microsserviços |
|---|---|---|
| Implantação | uma unidade, simples de subir | muitas, orquestração e coordenação |
| Coordenação interna | chamada de função, trivial | chamada de rede, que pode falhar |
| Autonomia de time | baixa, todos no mesmo código | alta, cada time no seu serviço |
| Consistência de dado | transação local, simples | distribuída, complexa (saga) |
| Escala | escala o bloco inteiro | escala cada serviço sob demanda |
Microsserviços cobram um imposto que o monólito não cobra, e ignorá-lo é a origem de metade dos arrependimentos. Dentro de um monólito, dois módulos conversam por uma chamada de função: instantânea, confiável, transacional. Entre dois microsserviços, a mesma conversa vira uma chamada de rede: pode ficar lenta, pode falhar, pode chegar duas vezes, e não há transação que abranja os dois. O que era um detalhe invisível vira um problema de engenharia com nome próprio, e cada chamada entre serviços precisa de timeout, retry, tratamento de falha e, muitas vezes, de uma saga para manter a consistência sem transação distribuída.
O imposto não para na comunicação. Observabilidade fica mais difícil, porque uma requisição atravessa muitos serviços e é preciso rastreamento distribuído para segui-la. Depuração vira arqueologia entre logs de várias origens. A operação multiplica: mais coisas para implantar, monitorar, versionar e manter compatíveis. E a consistência de dados, trivial num banco só, vira um problema profundo quando cada serviço tem o seu. Nada disso torna microsserviços errados; torna-os caros. O erro é adotá-los sem reconhecer o imposto, e descobrir tarde que a autonomia comprada não valeu o custo de operação que ela trouxe junto.
O meio-termo que o pêndulo revelou é o monólito modular, e ele desfaz o falso dilema. A ideia é ter os benefícios da divisão, módulos com fronteiras claras, responsabilidades separadas, times donos de partes, sem pagar o imposto do sistema distribuído, porque tudo continua num único deployable, comunicando por chamada de função. É a safah echat bem organizada: uma só língua e uma só implantação, mas com bairros internos bem delimitados, em vez de um cômodo único e caótico. O monólito ruim não é ruim por ser monólito; é ruim por ser uma bola de lama sem fronteiras internas.
O monólito modular também é a melhor preparação para uma eventual divisão. Se os módulos internos já têm fronteiras nítidas, alinhadas a contextos delimitados do DDD, extrair um deles para virar um serviço, quando a dor justificar, é uma operação cirúrgica, não uma reconstrução. Martin Fowler chama isso de monolith-first: comece monólito, descubra as fronteiras reais operando o sistema, e extraia serviços a partir dessas fronteiras já conhecidas, em vez de adivinhá-las no papel antes de o sistema existir. A divisão prematura erra as fronteiras, porque ninguém as conhece de véspera; a divisão a partir de um monólito modular maduro acerta, porque as costuras já foram descobertas na prática.
Se microsserviços custam caro, quando dividir compensa? As razões boas são concretas, não estéticas. Escala independente: um componente precisa escalar muito mais que o resto e carregá-lo dentro do monólito desperdiça. Autonomia de time: times grandes demais pisando no mesmo código se destravam com serviços separados, e aqui entra a lei de Conway, a arquitetura tende a espelhar a estrutura de comunicação da organização, então dividir serviços é também organizar times. Ritmo de mudança diferente: uma parte que muda toda hora convive mal com uma que quase não muda. Tecnologia diferente: um componente que pede outra linguagem ou runtime.
E há o antipadrão que reúne o pior dos dois mundos: o monólito distribuído. Acontece quando se divide em serviços, pagando todo o imposto de rede e operação, mas os serviços continuam tão acoplados que não podem ser implantados nem evoluídos de forma independente, uma mudança num obriga a mudar e reimplantar vários juntos. É o espalhamento de Babel sem o ganho da autonomia: perdeu-se a coordenação fácil do monólito e não se ganhou a independência dos microsserviços. A causa quase sempre é dividir pelas fronteiras erradas, tecnicamente, por camada, em vez de por contexto de negócio, e é por isso que DDD e a decisão de dividir são inseparáveis: sem as fronteiras certas, a divisão produz o pior dos dois mundos.
A relação com essa decisão amadurece do dogma ao trade-off consciente. No começo é o monólito bola de lama, sem fronteiras. Depois vem a fase da moda, microsserviços em tudo, muitos prematuros, alguns virando monólito distribuído. No meio vem o reconhecimento do imposto e a adoção do monólito modular como padrão. No topo é a decisão caso a caso, guiada por razões concretas de escala, autonomia e ritmo, com as fronteiras vindas do domínio, e serviços extraídos de um modular maduro só quando a dor justifica. Cada degrau troca a moda pela adequação ao contexto real.
Essa decisão amarra todo este eixo. As fronteiras vêm dos contextos delimitados do DDD; o monólito modular por dentro é a Clean Architecture aplicada em escala; a comunicação entre serviços, quando se divide, apoia-se na arquitetura orientada a eventos; e a operação da teia distribuída, se ela existir, cai sobre o Kubernetes, o service mesh e o resto do eixo de Cloud e Plataforma. A lição de Babel é a moldura certa: a unidade da safah echat dá poder de coordenação e é o ponto de partida sensato; o espalhamento traz autonomia ao preço de a coordenação virar difícil. Espalhar cedo demais, ou pelas fronteiras erradas, repete o erro de Babel sem a benção da autonomia, e a maturidade é saber quando a unidade ainda serve e quando o espalhamento finalmente vale o seu preço.
Monólito e microsserviços são a tensão de Babel: a safah echat, uma só língua e implantação, dá coordenação trivial; o espalhamento em serviços dá autonomia ao preço de a coordenação virar um problema de sistema distribuído. O pêndulo voltou ao monólito modular como padrão, unidade por fora e fronteiras claras por dentro, e a divisão como decisão deliberada por escala, autonomia ou ritmo, nunca por moda. O antipadrão é o monólito distribuído, que paga o imposto sem o ganho. A IA situa a decisão e opera a teia. Mas saber quando a unidade ainda serve, e quando espalhar vale o preço, continua sendo julgamento de arquitetura.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Engenhariaשֵׁמוֹת
A maior distância num projeto não é técnica, é entre o que o negócio diz e o que o código faz. DDD fecha essa distância nomeando o domínio com precisão: uma linguagem única entre quem entende o negócio e quem escreve o código, e fronteiras claras entre contextos onde a mesma palavra significa coisas diferentes.
Engenhariaסֵפֶר זִכָּרוֹן
Em vez de um serviço mandar no outro, cada um anuncia o que aconteceu, e quem se interessa reage. O evento é um fato registrado, como um livro de memória, e daí nascem o desacoplamento, o CQRS e o event sourcing, com o preço da consistência eventual e da depuração difícil.
