Jean Pierre Lessa e Santos Ferreira, especialista em tecnologia, software e inteligência artificial, observa que muitas empresas tornam seus sistemas complexos demais em nome de uma escala que ainda não existe. O resultado é uma arquitetura cara de operar e lenta para mudar.
O problema aparece cedo em projetos novos. Antes de ter mil clientes, a equipe já divide a aplicação em dezenas de serviços, adota orquestradores de contêineres e monta filas para cada interação. Meses depois, uma alteração simples exige mexer em cinco repositórios e coordenar três implantações.
Por trás dessa escolha está uma crença difundida no mercado: a de que sistema escalável é, necessariamente, sistema fragmentado. A ideia tem fundamento parcial, mas, aplicada fora de contexto, produz o efeito contrário ao desejado. Descubra mais a seguir.
De onde vem a ideia de que escalar exige complexidade?
Boa parte das referências de arquitetura vem de empresas com centenas de milhões de usuários e milhares de engenheiros. Os modelos que elas descrevem resolvem problemas reais, mas problemas daquela escala, com times grandes o bastante para manter cada serviço de forma independente.
Nessa perspectiva, Jean Pierre Lessa e Santos Ferreira destaca que copiar a arquitetura de uma gigante sem copiar suas condições é importar o custo sem o benefício. A divisão em serviços faz sentido quando equipes diferentes precisam evoluir partes do sistema em ritmos diferentes, e não antes disso.
Existe ainda um componente menos técnico. Tecnologias em evidência atraem profissionais e rendem boas apresentações, o que cria pressão para adotá-las. Só que a decisão de arquitetura precisa responder a perguntas do negócio, e não à vitrine do mercado de trabalho.
O custo que a complexidade precoce esconde
Quando uma função chama outra dentro do mesmo processo, a resposta é quase instantânea e não falha por problema de rede. Quando essa chamada atravessa dois serviços, surgem latência, tempo limite, novas tentativas e a possibilidade de uma parte da operação concluir enquanto a outra falha.
Cada fronteira entre serviços traz também custos operacionais. É preciso rastrear requisições distribuídas, versionar contratos entre equipes e manter esteiras de implantação separadas. Para um time pequeno, esse esforço consome o tempo que deveria ir para o produto.
Uma alternativa que tem ganhado espaço é o monólito modular. A aplicação continua sendo implantada como uma unidade, mas o código é organizado em módulos com fronteiras claras. Se um deles precisar crescer de forma independente no futuro, a separação já está desenhada.
Construir ou comprar: onde a simplicidade também se decide
A questão entre construir ou comprar é mais um aspecto em que a complexidade se acumula sem ser percebida. Banco de dados gerenciados, filas prontas e serviços de autenticação na nuvem eliminam a necessidade de equipes operacionais que teriam que ser formadas para gerenciar soluções internas.
Aliás, Jean Pierre Lessa e Santos Ferreira, que participou da construção de plataformas de varejo praticamente do zero, considera que o esforço próprio deve se concentrar no que diferencia o negócio. Marketplace e logística de última milha justificaram soluções proprietárias, enquanto a infraestrutura comum pode ser contratada.
O critério prático é perguntar se aquele componente é uma vantagem competitiva ou apenas uma necessidade. Um mecanismo de precificação próprio pode separar uma empresa das concorrentes. Um sistema de envio de e-mails construído em casa, na maioria dos casos, apenas adiciona manutenção.
Simplicidade é o que permite crescer depois
Arquitetura escalável não é a que suporta qualquer volume desde o primeiro dia. É a que pode ser alterada com segurança quando o volume real aparecer. Código organizado, dados bem modelados e métricas confiáveis valem mais nessa hora do que uma infraestrutura sofisticada e subutilizada.
A complexidade, nesse modelo, precisa ser justificada por números: um gargalo medido, uma equipe que cresceu, um componente com demanda muito diferente dos demais. Sem essa evidência, cada nova camada é um custo fixo pago por uma hipótese.
Com base nisso, Jean Pierre Lessa e Santos Ferreira resume que a boa arquitetura de soluções se reconhece pelo que deixou de fora. Cada decisão adiada com consciência preserva a capacidade de escolher melhor mais adiante, quando o sistema e o negócio já tiverem mostrado para onde precisam crescer.
