Escalabilidade não começa pelo banco de dados
Cada comunidade tem seus hábitos, muitas vezes conjuntos de tecnologias são comumente utilizados em conjunto, o que chamamos de stacks.
Desenvolvedores que vieram do universo .NET costumam estar mais próximos do SQL Server e Angular, quem aprendeu a programar com bootcamps focados em JavaScript provavelmente passou pela famosa stack MERN (MongoDB, Express, React, Node.js). Isso molda a forma como essas pessoas enxergam a aplicaçao como um todo, incluindo o backend e principalmente o banco de dados.
Muitas vezes isso acaba criando uma visão limitada sobre o que é possível ou desejável tecnicamente.
Pra quem só conhece bala de prata, todo problema é um lobisomen
Nas faculdades, por sua vez, muito focadas em teorias mais consolidadas, acabamos aprendendo somente o que diz respeito a bancos de dados relacionais. A dificuldade de conseguir mudar uma grade curricular ou até mesmo o conhecimento dos professores acaba limitando o aprendizado, criando tendencias e predisposições em muitos desenvolvedores.
Profissionais com maior senioridade, por sua vez, acabam enxergando os bancos relacionais como tecnologias antiquadas por terem enfrentados projetos legados com má práticas e quando se fala em escalar um backend, muitos pensam diretamente em abandonar bancos relacionais e partir pra soluções NoSQL, mas vamos falar de overengineering mais pra frente.
É uma reação comum, como se fosse uma fórmula pronta. Mas a verdade é que a escolha da tecnologia, especialmente do banco de dados, deveria vir depois de entender o problema e o contexto do sistema. Nem sempre o que parece moderno ou promissor na teoria é o que vai funcionar melhor na prática.
Muitos pensam na aplicação sendo pensada como um simples "wrapper" para o banco de dados, isso não é data driven .
Nesse cenário, a lógica de negócio quase vira um tradutor entre a interface e os dados, o que dificulta decisões mais arquiteturais e abre pouco espaço para abstrações mais poderosas e reutilizáveis.
Um disclaimer é que ta tudo bem se você só quer criar um MVP ou uma aplicaçao de pequeno porte sem muitos gastos, pra poder validar uma ideia ou começar a captar alguns clientes mas aqui falamos sobre escalabilidade e se você ta passando por uma reescrita ou manutenção de um sistema que tem escala como requisito, quanto mais rápido você entender o tradeoff, mais dinheiro é possivel que voce economize.
Entendendo os bancos: o problema da incompatibilidade de impedância
Lendo o livro "NoSQL Essencial" tive um insight interessante sobre um problema que eu não sabia que tinha um nome, a ideia de que bancos relacionais trazem consigo um desafio chamado incompatibilidade de impedância. Esse nome complicado descreve uma situação simples (e bem comum): o fato de que objetos no código e registros no banco de dados não "conversam" de forma natural.
É preciso uma camada de tradução (como os ORMs) que nem sempre é eficiente, e pode acabar gerando mais dor de cabeça.
O uso excessivo de mappers e a complexidade agregada desanima muitos desenvolvedores e tende a se tornar um problema no futuro caso o sistema seja muito acoplado e tenha efeitos colaterais.
Por outro lado, o uso de bancos NoSQL muitas vezes vem do comodismo ou da moda, e não de uma análise cuidadosa dos requisitos. Projetar sistemas pensando somente nas tecnologias e não nos problemas e nas regras de negócio pode ser prejudicial, dificultando manutenções e novas implementações, pra corrigir, muitas vezes, só com reescrita.
O que realmente importa: repertório, cultura e timing
O que diferencia um time sênior não é escolher a "melhor" tecnologia, mas saber quando e por que adotá-la. Ter repertório técnico e vivência com diferentes tipos de ferramentas permite discutir soluções com profundidade (e não com base em hype).
Escalar uma aplicação para milhões de usuários exige esse tipo de maturidade técnica.
Isso não se aprende do dia pra noite. Começa com uma cultura de desenvolvimento saudável, que valoriza o aprendizado contínuo, boas práticas de engenharia e decisões pensadas, isso é engenharia de software.
Passa por entender conceitos de arquitetura, estratégias de testes, automações de CI/CD e, principalmente, por evitar excessos: aquele impulso de criar soluções complexas para problemas que ainda nem existem ou só pra poder colocar uma tecnologia nova no currículo.
Por favor, dev, você tendo cursado ou não uma faculdade, seu trabalho reside encima de ciência, portanto, façamos ciência.
O core do sistema vem primeiro
Antes de sair escolhendo tecnologias, é preciso entender e modelar bem as regras de negócio. Isso quer dizer construir um core estável e limpo, independente das ferramentas ao redor. Só depois disso faz sentido pensar no que vamos "plugar": seja um Redis, um MongoDB, uma fila com RabbitMQ ou o que for necessário.
Quando a aplicação é bem estruturada e existe orçamento pra melhorias, o time deve ter liberdade e segurança para trocar ou introduzir ferramentas conforme a necessidade real. E aí sim é possível falar de escalabilidade de verdade — aquela que é baseada em decisões técnicas sólidas, e não em tendências passageiras.
Deixo aqui um bate papo que tive há um ano atrás com a Cubos Academy que pode servir de preparo pro nosso próximo post em que começaremos a falar sobre arquitetura de software.
Veja abaixo:
referências
Café & Tech: Introdução à Arquitetura de Software
NOSQL Essencial - Martin Fowler, Pramod J. Sadalage