o ponto de partida
Se tem uma coisa que poucos cursos ensinam e que muitas empresas escondem, é o fluxo que um sistema passa para chegar até a produção. Parece algo trivial, mas acredite: já conheci desenvolvedores seniores que nunca tiveram a esperiência de fazer um deploy. Isso porque atualmente, em empresas de grande porte, é comum existirem processos extremamente burocráticos e ferramentas automatizadas que cuidam disso.
Mas o que acontece quando você sai desse ambiente e precisa colocar um sistema no ar sozinho? Antes de falar sobre escalabilidade, precisamos entender o que significa colocar um sistema em produção de forma profissional. Isso inclui desde o básico: como funcionam a internet, os servidores, o DNS e a hospedagem — até questões mais complexas como estratégias de CI/CD e monitoramento.
Aqui entra uma questão importante: antes de escalar, um sistema precisa existir.
Por muito tempo, sistemas foram construídos de forma mais simples, sem grandes preocupações com crescimento e com o aumento da demanda por transformação digital isso mudou de forma abrupta.
O modelo mais comum costumava ser o monolito: um único aplicativo rodando em um unico servidor, atendendo todas as requisições, muitas vezes até mesmo compartilhando recursos com o banco de dados. Para poucos usuários isso funcionava bem, escalar era uma questão de adicionar mais poder de processamento, chamamos de escalabilidade vertical. Mas será que essa abordagem funciona quando falamos de milhares ou milhões de requisições?
Essa acabou sendo a realidade de muitos sistemas por anos e ainda é um modelo válido quando bem dimensionado. No entanto, conforme a demanda cresce, surgem desafios que precisam ser resolvidos para que o sistema continue funcionando de forma eficiente, uma vez que hardware potente é caro e explorar os recursos da máquina de forma eficiente também é um desafio.
monolitos e a falsa urgência dos microsserviços
Por muito tempo, sistemas foram construídos seguindo o modelo MVC (Model-View-Controller) com tecnologias como .NET, Java e PHP. Esses sistemas geralmente rodavam em uma única máquina, onde toda a lógica de negócio, sessões de usuário e conexões com o banco de dados estavam centralizadas.
Escalar um monolito exigia um pensamento diferente: como distribuir sessões de usuários? Como evitar gargalos no banco? Como reduzir a carga no servidor? A solução passava por separar melhor o tratamento das conexões, armazenar sessões de usuário em sistemas NoSQL com maior velocidade de leitura e implementar cache para reduzir acessos diretos ao banco de dados. Era um trabalho duro, mas ainda assim possível.
Imagine que seu sistema tem milhares de usuários logados simultaneamente, e cada um precisa manter uma sessão ativa no servidor.
Se essas sessões estão armazenadas apenas na memória local, cada nova instância de aplicação criada para suportar a demanda perde essas informações. Esse é um dos desafios mais comuns ao escalar um monolito, e soluções como Redis ajudam a manter a consistência das sessões entre múltiplas instâncias.
Hoje, com a facilidade da cloud e com estratégias cloud native em muitas empresas esse problema já nao existe mais. Infraestrutura escalável está a um clique de distância, e isso fez com que muitas empresas passassem a gastar muito mais do que o necessário. Em vez de otimizar um sistema monolítico para suportar um volume maior, muitos times caem na armadilha de partir direto para microsserviços sem antes validar a necessidade real.
Esse é um dos maiores erros quando se fala em escalabilidade. A cloud trouxe um avanço enorme em tecnologia e muitas facilidades, mas sem um bom planejamento, o custo pode escalar tanto quanto o sistema. Dividir um sistema em microsserviços sem dimensionamento adequado pode gerar complexidade desnecessária, dificultar a manutenção e aumentar os custos sem ganhos reais de desempenho. Antes de qualquer decisão, é essencial saber realizar testes de carga no sistema e entender como otimizá-lo sem perder eficiência.
Além disso, sistemas distribuídos trazem novos desafios, tal qual os problemas de invalidação de cache e de consistência eventual, uma vez que múltiplos serviços podem estar servindo dados desatualizados por não conseguirem invalidar caches corretamente entre instâncias ou por múltiplos sistemas estarem inserindo e atualizando dados que seriam necessários a outro ao mesmo tempo, isso deve ser considerado no design da aplicação.
Investir tempo em otimizar um monolito antes de sair quebrando serviços pode economizar milhares de dólares em infraestrutura. Dimensionar corretamente o sistema e realizar monitorar seu funcionamento são passos fundamentais para garantir que a escalabilidade seja feita de forma sustentável.
o erro comum na adoção de microsserviços
Muitas empresas se inspiram em cases de sucesso como Netflix, Uber e Amazon para justificar a adoção de microsserviços, mas ignoram a complexidade que essas empresas enfrentam para alcançar milhões de acessos em sistemas distribuídos. Palestras como Mastering Chaos, da Netflix, mostram que para operar nesse nível é preciso muito mais do que apenas dividir um sistema: exige governança, automação, uma grande capacidade técnica e uma forte cultura de DevOps.
Sem esses pré-requisitos, o que acaba sendo produzido no mercado são monolitos mal modularizados, serviços mal distribuídos e contextos que simplesmente são adicionados ao sistema sem uma visão técnica prévia. Mandates sobre o uso de microsserviços são implementados sem entender os requisitos do negócio, resultando em sistemas difíceis de manter, evoluir e escalar.
Além disso, a adoção de microsserviços exige uma mudança na mentalidade da empresa. Para funcionar é preciso construir uma cultura sólida de DevOps e arquitetura de sistemas, garantindo a existência de CI/CD, testes automatizados, controle sobre a infraestrutura e estratégia de mitigação de danos. Sem esses pilares, a empresa arrisca substituir um monolito difícil de escalar por um conjunto caótico de serviços desconectados.
Construir escalabilidade eficiente vai muito além de escolher entre monolitos e microsserviços. O que importa é ter ciência do impacto de cada decisão e garantir que há planejamento e controle para evitar problemas estruturais no futuro.
adoção dos 12 Fatores
Uma abordagem sólida para guiar a construção de sistemas escaláveis e bem projetados é seguir a metodologia twelve-factor app escrita por Adam Wiggins. Esses princípios estabelecem boas práticas para o desenvolvimento de aplicações modernas, garantindo que elas sejam portáveis, resilientes e fáceis de manter.
Os 12 fatores abordam desde o controle de dependências e configuração, até práticas de deploy, escalabilidade e logs estruturados. Empresas que adotam esses princípios desde o início criam sistemas mais fáceis de operar e menos propensos a falhas inesperadas.