A palestra "Front-end em escala: O que quebra primeiro em aplicações com milhões de usuários?", no palco Stadium do TDC São Paulo, tratou de um ponto que costuma passar batido em discussões técnicas: antes de falar de performance de runtime, é preciso falar de governança.
Governança: quem decide o quê?
Um dos slides projetados resumiu bem o problema: "100 profissionais → 100 decisões → 100 interpretações". Sem definições claras de arquitetura, stack, padrões, documentação e responsáveis por consistência visual e métricas, cada pessoa do time acaba tomando decisões isoladas — e isso cobra um preço alto depois.
"Tem uma pessoa nova chegando no time. Como é que essa arquitetura foi definida? Qual foi o histórico até a gente chegar nesse ponto aqui? E muitas vezes a gente não tem esse histórico."
A sugestão apresentada foi investir em RFCs para documentar decisões e abrir espaço para quem quiser contribuir com o debate técnico. Como reforçou um dos slides: "Nenhuma arquitetura sobrevive sem acordos."
Dependências não são só o que você instala
Outro ponto central foi o tratamento de dependências — e a apresentação deixou claro que o conceito vai além do npm install: "a dependência, ela vai ser qualquer código externo que a gente vai ter ali que o nosso código vai funcionar". Isso inclui vulnerabilidades ignoradas (aquele clássico npm audit com alertas críticos que ninguém resolve), incompatibilidades, tempo de build crescente e bundles inchados.
A recomendação prática, também destacada em slide: "Conheça suas dependências, classifique sua criticidade e defina o comportamento da aplicação quando cada uma delas falhar."
Resiliência é lidar com a falha, não evitá-la
Com milhões de usuários, falhas em integrações externas (o exemplo citado foi um provedor de pagamento como o PayPal) deixam de ser hipótese e passam a ser rotina. A apresentação listou estratégias como retries automáticos combinados com circuit breakers — para evitar que uma tentativa de recuperação vire uma sobrecarga no servidor — além de mecanismos de fallback. A síntese ficou no slide: "Resiliência não significa evitar falhas, mas sim saber lidar com essas falhas quando elas acontecem."
O fator humano da escala
Por fim, a palestra chamou atenção para uma variável frequentemente esquecida: as pessoas. Conhecimento concentrado em poucas pessoas, alta rotatividade e a saúde mental do time são riscos reais para aplicações que atendem milhões de usuários diariamente.
"Se hoje, por exemplo, cinco pessoas saírem do time de uma vez, como é que esse time que ficar vai se reorganizar para manter aquela aplicação que está atendendo dez milhões de pessoas todos os dias?"
O slide final resumiu o recado: "Escalar pessoas é mais difícil que escalar aplicações" — e escalabilidade, no fim das contas, "não é [apenas] suportar milhões de usuários". Para times brasileiros que crescem rápido, a mensagem é clara: arquitetura técnica sem governança, gestão de dependências e cuidado com pessoas é uma escala incompleta.