Escala e performance — a diferença real entre 300 e 5.000 usuários
Decisões que funcionam bem num tamanho podem quebrar em outro — e isso não é sobre 'código ruim'.
Por que escala muda tudo
Gargalo
Escala vertical x horizontal
Cache e fila, sob carga
00 — POR QUE ESCALA MUDA TUDO
O que funciona com 300 usuários pode não aguentar 5.000
Um sistema que responde rápido com 300 pessoas usando ao mesmo tempo pode começar a travar, atrasar ou até cair com 5.000 — não necessariamente porque o código foi mal escrito, mas porque certos gargalos só aparecem quando existe volume real de gente batendo no sistema ao mesmo tempo. Planejar pra escala é decidir, desde cedo, quais partes do sistema aguentam crescer e quais vão precisar de atenção quando o uso aumentar.
Metáfora: uma porta de entrada funciona bem pra 10 pessoas passarem por vez. Com 5.000 pessoas tentando entrar no mesmo minuto, mesmo a porta mais bem construída vira um gargalo — o problema não é a porta em si, é o volume que ela nunca foi pensada pra atender.
01 — GARGALO
O ponto mais lento decide a velocidade do sistema inteiro
Um gargalo é a parte mais lenta de um sistema — o ponto que limita a velocidade de tudo, não importa quão rápido seja o resto. Mesmo que 95% do sistema seja extremamente rápido, se uma consulta ao banco de dados ou uma chamada a uma API externa demora muito, é essa parte lenta que define o tempo total de resposta sentido pelo usuário.
Metáfora: numa estrada de várias pistas que de repente estreita pra uma pista só, o trânsito nunca flui mais rápido do que aquele trecho estreito permite — não importa quão largas sejam as pistas antes e depois dele.
Por que isso importaAo investigar lentidão com a IA, a pergunta certa não é "o sistema está lento", e sim "qual parte específica está lenta" — geralmente uma consulta ao banco mal otimizada ou uma chamada externa demorada.
reconhecer 1 — gargalopendente
O que define o tempo total de resposta de um sistema, mesmo que a maior parte dele seja rápida?
AA parte mais lenta do sistema — o gargalo
BA média entre todas as partes, rápidas e lentas
CSempre o frontend, nunca o backend
02 — ESCALA VERTICAL X HORIZONTAL
Deixar uma máquina mais forte, ou somar mais máquinas iguais
Existem duas formas básicas de dar mais capacidade a um sistema. Escala vertical é aumentar a força de uma única máquina — mais memória, mais processamento. Escala horizontal é adicionar mais máquinas rodando a mesma aplicação em paralelo, dividindo a carga entre elas — foi exatamente esse o papel do reverse proxy visto no Módulo 3, que pode distribuir pedidos entre várias cópias do mesmo serviço.
Metáfora: escala vertical é contratar um caixa de supermercado muito mais rápido. Escala horizontal é abrir mais caixas atendendo ao mesmo tempo. Os dois resolvem a fila — só que de jeitos diferentes, com limites e custos diferentes.
No seu projetoO PM2, que já roda todos os seus projetos na VPS, suporta escala horizontal nativamente — basta aumentar o número de "instances" de um app pra rodar várias cópias dele em paralelo, quando o volume justificar.
reconhecer 2 — escala vertical x horizontalpendente
O que caracteriza a escala horizontal?
AAumentar a capacidade de uma única máquina (mais memória ou processamento)
BAdicionar mais máquinas rodando a mesma aplicação em paralelo, dividindo a carga entre elas
CReduzir o número de usuários simultâneos permitidos
03 — CACHE E FILA, SOB CARGA
Duas ferramentas que aliviam a pressão quando o volume cresce
O cache, visto no Módulo 6, se torna ainda mais importante sob escala: evitar repetir a mesma busca cara no banco pra milhares de pedidos idênticos reduz drasticamente a pressão sobre o gargalo. Já uma fila de processamento serve pra tarefas pesadas que não precisam de resposta imediata — em vez de travar o pedido principal esperando um processamento demorado terminar, o sistema coloca essa tarefa numa fila e responde ao usuário na hora, processando o resto em segundo plano.
Metáfora: é a diferença entre atender cada pedido de um restaurante na hora que chega, um de cada vez direto na cozinha (travando tudo), e anotar o pedido, avisar "já vai sair", e preparar em ordem, sem deixar ninguém esperando parado no balcão.
reconhecer 3 — cache e fila sob cargapendente
Qual é a vantagem de colocar uma tarefa pesada numa fila, em vez de processá-la direto durante o pedido do usuário?
AO usuário recebe uma resposta rápida, enquanto a tarefa pesada é processada em segundo plano, sem travar o pedido principal
BA fila elimina completamente a necessidade de processar a tarefa
CA fila substitui a necessidade de banco de dados
desafio final do módulo 10: Seu sistema começou a demorar muito pra responder depois que o número de usuários simultâneos aumentou. Uma investigação mostrou que uma única consulta ao banco de dados está demorando 4 segundos, enquanto todo o resto do sistema responde em milissegundos. Qual é o diagnóstico e o próximo passo mais coerente com este módulo?
desafio finalpendente
Escolha a alternativa mais coerente com os conceitos deste módulo.
AEssa consulta lenta é o gargalo do sistema; vale considerar cache pra ela, ou otimizar a consulta, antes de gastar esforço escalando as outras partes que já são rápidas
BEscalar horizontalmente o frontend resolve, já que o problema está no banco de dados
CComo o resto do sistema é rápido, a lentidão de 4 segundos não é relevante