Arquitetura para aplicativos escaláveis: o que decidir antes do código
Escala não se compra depois com servidor maior — se projeta antes, nas decisões de dados, API e infraestrutura. As cinco decisões que separam apps que crescem de apps que travam.
Escalabilidade é decisão, não hardware
Quando um app trava com o triplo de usuários, a reação comum é "aumenta o servidor". Às vezes funciona — por um tempo. Mas os gargalos reais quase sempre nasceram meses antes, em decisões de arquitetura tomadas (ou não tomadas) no início.
As cinco decisões que definem o teto
- Modelagem de dados: o esquema do banco é a decisão mais cara de mudar depois. Consultas que varrem tabelas inteiras funcionam com mil registros e morrem com um milhão.
- Fluxo de dados: mandar tudo para o app e filtrar na tela é o anti-padrão clássico — prepare no servidor o que cada tela precisa (foi assim que levamos uma resposta de 25 MB para 23 KB).
- Trabalho assíncrono: o que não precisa de resposta imediata (email, relatório, processamento) sai da requisição e vai para fila — a experiência do usuário não espera o trabalho pesado.
- Estado e cache: decidir o que pode ser cacheado, por quanto tempo e onde (dispositivo, borda, servidor) é metade da performance percebida.
- Observabilidade: sem métricas e rastreamento desde o início, todo problema de escala vira adivinhação em produção.
O falso atalho dos microsserviços
Microsserviços não são sinônimo de escala — são um custo operacional alto que se justifica em times grandes e domínios complexos. Para a maioria dos produtos, um monólito bem modularizado escala mais longe do que se imagina, e se divide depois, quando (e se) a fronteira certa aparecer.
Como aplicamos isso
É o coração do Framework Córtex: a fase de arquitetura vem antes do código, com decisões documentadas (ADRs) explicando cada escolha e o teto que ela suporta. Custa dias no início do projeto — e evita os meses de reescrita que são o custo oculto mais comum do mercado.