Imagine um sistema com 500 usuários ativos. Ele não sofre com gargalo de banco de dados, não tem problemas de concorrência massiva e roda confortavelmente em qualquer servidor modesto. Ainda assim, a arquitetura por trás dele conta com dezenas de microsserviços, clusters Kubernetes, tópicos no Kafka e uma malha de serviços ultra-complexa que drena o faturamento do negócio. O resultado prático? O deploy vira um inferno burocrático e a conta da nuvem consome a margem de lucro. A complexidade nas organizações não nasce de necessidades de engenharia, mas sim da distorção de incentivos do mercado e do ego profissional.

Uma Micro-História Realista

Considere o cenário de uma startup nacional de logística urbana que, em sua fase de validação, possuía uma equipe de apenas oito desenvolvedores. Pressionada pela promessa de escalabilidade de nuvem, a engenharia decidiu fatiar o sistema nascente em trinta microsserviços baseados em contêineres e uma malha complexa de mensageria. Em menos de um ano, o time gastava mais de 40% do seu orçamento mensal apenas pagando faturas de infraestrutura distribuída que rodava ociosa, enquanto as entregas de novas funções de negócio para os clientes atrasavam meses devido ao atrito de manter a rede funcional. O problema real de concorrência que tentavam antecipar simplesmente nunca existiu.

1. O Pêndulo da Computação: Ciclos Históricos

O debate entre monolitos e microsserviços não é novo. Na verdade, a história da tecnologia funciona como um pêndulo que oscila constantemente entre a centralização e a descentralização:

O perigo reside em tratar essas oscilações históricas como dogmas sagrados, ignorando os custos intrínsecos de cada escolha arquitetural.

2. O Efeito Manada e a Sobrecarga (Overengineering)

O primeiro pilar que sustenta essa complexidade desnecessária é o Efeito Manada. Cria-se o mito de que se uma Big Tech adota uma determinada ferramenta ou infraestrutura pesada, esse passa a ser o padrão ouro obrigatório de engenharia. O mercado esquece que o que serve de remédio para uma empresa que lida com milhões de transações por segundo vira veneno e falência para um sistema comum de comércio ou varejo.

Por exemplo, considere uma fintech que processa cerca de 20.000 transações diárias. Adotar um cluster distribuído de tópicos Kafka para coordenar transações que poderiam ser resolvidas de forma atômica e segura com transações ACID nativas do banco de dados relacional é um caso clássico de sobre-engenharia. A empresa troca a simplicidade transacional por problemas de consistência eventual e latência sem qualquer ganho prático de negócios.

3. O Fenômeno do CV-Driven Development (Desenvolvimento Orientado a Currículo)

O segundo pilar, de ordem psicológica e de mercado, é a distorção das vagas de emprego. Se uma descrição de vaga para desenvolvedor exige dominar "Kubernetes, Kafka, Istio, gRPC, Cassandra, Redis e AWS" apenas para manter um sistema interno de cadastro, o profissional que passa anos cuidando de um monolito modular simples e rentável sente que está ficando obsoleto.

Essa distorção induz a Arquitetura Orientada a Currículo: a introdução artificial de tecnologias complexas nos projetos da empresa com o principal objetivo de rechear o portfólio dos desenvolvedores e valorizar seus passes no mercado. A engenharia passa a servir ao ego dos profissionais em vez de visar a saúde financeira do produto.

4. Monolito não é Código Ruim

Para qualificar a discussão, precisamos separar a forma física do executável da qualidade lógica do design do código. Há uma diferença brutal entre:

• Monolito de Lama: Uma aplicação unificada onde o código de faturamento, estoque e usuários é totalmente misturado, sem regras de dependências ou fronteiras lógicas claras (o clássico espaguete).
• Monolito Modular: Um único executável e banco de dados, porém com pacotes internos rigidamente isolados e blindados, garantindo que alterações em um módulo não afetem os demais de forma inesperada.

Se uma equipe não consegue manter a ordem conceitual do código dentro de um único repositório, ela jamais conseguirá organizar esse código se optar por espalhá-lo por dezenas de servidores independentes interligados pela rede.

Conclusão

A decisão arquitetural deve ser guiada por métricas frias de volumetria e restrições econômicas de infraestrutura. Não podemos deixar que a pressa por adoção ou incentivos de carreira substituam a análise racional de dados.

Erro comum: A complexidade de um sistema de software não nasce da tecnologia disponível — ela nasce da estrutura de incentivos que rege a equipe.

No próximo artigo, entraremos na camada técnica e matemática da computação distribuída: como a latência de rede e leis de concorrência provam estatisticamente se a separação arquitetural faz sentido para a sua volumetria de dados ou se é apenas queima de capital.

— Fim do Episódio 1. Continua no Artigo 02: “A Matemática da Escala — Volumetria, Rede e a Teoria das Filas”.

Tags de compartilhamento:
#SoftwareArchitecture #EngineeringCulture #CareerDevelopment #Monolith