Jean Pierre Lessa e Santos Ferreira conhece bem o momento em que um produto digital bem-sucedido encontra seu próprio limite: quando o crescimento de usuários supera a capacidade da infraestrutura construída para suportá-lo. Para o CTO, evitar esse colapso não é questão de sorte, é resultado de decisões arquiteturais tomadas muito antes do pico de tráfego acontecer. Escalabilidade não se improvisa. Se projeta. E o custo de não projetá-la corretamente pode ser definitivo para um produto.
A aceleração da transformação digital tornou esse tema ainda mais urgente. Empresas que antes tinham anos para amadurecer sua infraestrutura agora precisam estar prontas para crescer em semanas. Plataformas de pagamento, aplicativos de saúde, marketplaces e soluções B2B enfrentam variações de carga que exigem sistemas capazes de expandir e contrair sem intervenção manual. E a linha entre um sistema escalável e um que não é costuma ser invisível até o dia em que não é mais.
Adiar decisões de escalabilidade realmente economiza tempo e dinheiro?
Jean Pierre Lessa e Santos Ferreira aponta a frase “vamos resolver isso quando crescer” como uma das mais caras do vocabulário da engenharia de software. O raciocínio parece prático: por que investir em infraestrutura para um tráfego que ainda não existe? O problema é que refatorar um sistema sob pressão de crescimento, com usuários ativos, operações em produção e time sobrecarregado, é exponencialmente mais caro e arriscado do que projetar com escalabilidade em mente desde o início.
Não se trata de over-engineering. Trata-se de tomar decisões que não fechem portas: escolher um banco de dados que suporte sharding horizontal, separar domínios de forma que possam escalar de forma independente e definir fronteiras claras de serviço que permitam redistribuição de carga. Essas decisões custam pouco no começo e evitam crises no futuro.
Caching: sua equipe usa essa ferramenta como estratégia ou só quando o problema já apareceu?
Uma das ferramentas mais eficazes para escalar sistemas de leitura intensiva é o cache, e também uma das mais mal utilizadas. Em muitos sistemas, ele é introduzido como solução de emergência quando o banco de dados começa a dar sinais de sobrecarga. Funciona no curto prazo, mas encobre problemas que vão ressurgir.
Como diretor de tecnologia, Jean Pierre Lessa e Santos Ferreira indica que o caching seja tratado como estratégia arquitetural desde o início. As decisões que fazem diferença real no comportamento do sistema sob carga incluem:
- O que deve ser cacheado, priorizando dados com alto volume de leitura e baixa frequência de atualização?
- Por quanto tempo cada dado permanece válido, equilibrando consistência e performance?
- Qual estratégia de invalidação será usada, evitando que dados desatualizados comprometam a experiência do usuário?
- Onde o cache será posicionado na arquitetura? Na camada de aplicação, no banco de dados ou em um serviço dedicado?
- Como monitorar a taxa de acerto para garantir que o cache está sendo efetivamente utilizado?
Ferramentas como Redis e Memcached, quando aplicadas com essa lógica desde o início do projeto, reduzem drasticamente a pressão sobre as camadas mais lentas da aplicação e evitam as crises de emergência que tanto consomem tempo e energia dos times de engenharia.
Banco de dados: o gargalo que ninguém quer encarar
Em grande parte dos sistemas que falham sob escala, o ponto de colapso é o banco de dados. Não porque o banco escolhido seja ruim, mas porque foi dimensionado para um volume que o sistema ultrapassou, ou porque o modelo de dados não foi pensado para consultas em larga escala. A decisão entre bancos relacionais e NoSQL continua sendo um dos debates mais relevantes da engenharia de software, e não há resposta universal, apenas trade-offs.
Jean Pierre Lessa e Santos Ferreira aponta que estratégias como read réplicas, particionamento de dados e separação entre banco de escrita e leitura são caminhos consolidados para estender a vida de sistemas relacionais em ambientes de alta escala, desde que adotadas antes de a situação se tornar crítica.
Você não pode escalar o que não enxerga
Sistemas escaláveis precisam de instrumentação. Logs, métricas e rastreamento distribuído não são luxo, são o sistema nervoso da infraestrutura. Sem visibilidade sobre o que acontece em cada camada da aplicação, identificar gargalos sob pressão vira exercício de adivinhação.
Para Jean Pierre Lessa e Santos Ferreira, especialista em desenvolvimento de software e infraestrutura, a observabilidade precisa ser construída junto com o sistema, não adicionada depois. Ferramentas como Prometheus, Grafana e OpenTelemetry criaram um ecossistema robusto para isso. O desafio não é mais técnico, é cultural: times precisam tratar métricas como parte do produto. Escalar bem é, no fundo, uma questão de visão de longo prazo aplicada a decisões de curto prazo.
Autor: Diego Rodríguez Velázquez
