Toda aplicação funciona bem com 100 usuários. A maioria também funciona bem com 10 mil. O problema, mostrou a apresentação "Front-end em escala: O que quebra primeiro em aplicações com milhões de usuários?", no palco Stadium, começa quando essa mesma aplicação passa a ter 10 milhões de usuários, 300 desenvolvedores e dezenas de times fazendo deploy todos os dias.
Pare de olhar para a média
O ponto central da palestra é que, em alta escala, "a gente precisa deixar de olhar só para aquele comportamento médio [...] e a gente vai precisar começar a olhar e gerenciar caudas". Um exemplo com LCP (Largest Contentful Paint) ilustrou bem o problema: com P50 em 1,8s e P75 em 2,5s (dentro do recomendado), o P95 salta para 5,7s e o P99 para 12 segundos — ou seja, 1% dos usuários enfrenta um carregamento seis vezes pior que o ideal. Como destacou a apresentação, "quando a gente fala de 1% de milhões, ainda é muito baixo" em termos absolutos de usuários afetados, mas alto o suficiente para gerar reclamações e perda de conversão.
A recomendação prática é monitorar um conjunto de métricas além dos Core Web Vitals isolados: TTFB, FCP, long tasks, tempo de execução de JavaScript, page weight e error rate — todas exibidas juntas no slide de métricas.
Microfrontend não resolve sozinho
A palestra reforçou que microfrontends trazem benefícios reais — deploy independente, autonomia entre times, reuso entre canais (web e mobile, por exemplo) — mas "quando a gente está falando em alta escala, muitas vezes ele vai trazer alguns problemas também": dependências duplicadas, falta de versionamento combinado, observabilidade fragmentada e, principalmente, dúvidas de governança: "quem que cuida de fato desse microfrontend na hora que ele quebrar?"
Design system é mais que um pacote NPM
Outro ponto forte: com muitos times trabalhando em paralelo, "a gente não pode ter 100 times reinventando um botão". Mas um design system maduro não se resume a instalar um pacote — segundo a apresentação, ele envolve identidade visual, acessibilidade, responsividade, versionamento, documentação, estratégia de migração, roadmap de features e adoção orgânica pela cultura da empresa.
Governança e pipeline como gargalos silenciosos
Com 100 profissionais tomando decisões isoladas, o risco é ter "100 decisões [e] 100 interpretações" sobre arquitetura, stack e padrões — por isso a defesa de ADRs (Architecture Decision Records) documentados: "nenhuma arquitetura vai sobreviver sem acordos".
Por fim, a palestra alertou para o CI/CD como gargalo prático: builds de 30 minutos que travam quando é preciso fazer 500 deploys por dia. Entre as soluções citadas estão Nx e Turborepo, para builds incrementais, cache remoto e paralelização — reforçando que "a performance de aplicações é importante, mas a performance de engenharia também é".
Para times brasileiros que sonham em escalar, o recado é claro: performance, arquitetura e governança precisam evoluir juntas antes que o crescimento de usuários exponha os pontos frágeis.