Isso não é falha de implementação. É consequência de uma realidade arquitetural: sistemas são construídos para o tráfego que existe, não para o tráfego que vai existir. E quando o crescimento é rápido, a distância entre os dois se torna um problema de produção.

Os três estágios do crescimento e o que quebra em cada um

Estágio 1: De 0 a 1.000 usuários/dia

Nesse estágio, um único servidor resolve. VPS de entrada aguenta. Banco de dados e aplicação coexistem na mesma máquina. Cache é simples ou inexistente. Tudo parece funcionar.

O que quebra: quando o tráfego dobra de forma súbita (uma menção em mídia, um post viral, uma campanha que performou além do esperado) o servidor único não tem onde escalar. Não há uma camada de distribuição. O gargalo é imediato.

Estágio 2: De 1.000 a 10.000 usuários/dia

A primeira solução típica é o upgrade vertical: mais RAM, mais CPU. Funciona por um tempo. Depois a arquitetura monolítica começa a mostrar seus limites, banco compartilhado com a aplicação cria contenção de I/O, ausência de cache aumenta a carga em cada requisição, ausência de CDN faz o servidor servir imagens e assets estáticos.

O que quebra: banco de dados. É o gargalo de 90% dos sites nesse estágio. Separar banco de dados e aplicação em servidores distintos é o primeiro passo que resolve mais do que qualquer upgrade de hardware.

Estágio 3: De 10.000 a 100.000 usuários/dia

Aqui, a arquitetura precisa ser repensada de forma mais profunda. Um único servidor de aplicação não consegue atender a demanda. O banco, mesmo dedicado, começa a ser ponto de contenção. A ausência de escalabilidade horizontal torna qualquer spike de tráfego um incidente.

O que quebra: a ausência de load balancing. Múltiplas instâncias da aplicação, distribuindo carga entre si, com um load balancer na frente, esse é o padrão arquitetural que resolve esse estágio. Junto com isso, read replicas para separar queries de leitura (maioria) das de escrita.

O problema das sessões quando você escala horizontalmente

Quando você passa de um servidor para múltiplos, surge um problema que parece simples mas quebra muitos sites em produção: sessões de usuário.

Na arquitetura de servidor único, sessões são armazenadas localmente. O usuário faz login no Servidor A, a sessão está lá. Com load balancer distribuindo entre Servidor A e Servidor B, a próxima requisição do mesmo usuário pode chegar no Servidor B, que não tem a sessão. O usuário é deslogado. O carrinho some. A experiência é destruída.

Sessões precisam ser externas ao servidor de aplicação antes de qualquer horizontalização. Redis é o padrão: todas as instâncias leem e escrevem sessões no mesmo Redis centralizado. Para o usuário, a experiência é contínua, independente de qual instância responde.

O mesmo problema aparece com uploads de arquivos (armazenados localmente, invisíveis para outras instâncias), cache de aplicação (cada servidor tem seu cache local, invalidações não se propagam) e filas de processamento (jobs criados por uma instância precisam ser visíveis para todas).

A solução é o mesmo princípio: externalizar o estado. Sessões no Redis. Arquivos em object storage (S3, R2, MinIO). Cache no Redis. Filas em RabbitMQ ou Redis Streams. O servidor de aplicação vira stateless, qualquer instância pode servir qualquer requisição porque nada de estado vive nela.

Monolito vs. microsserviços: a decisão prematura que mata projetos

Quando um site começa a crescer, é comum a recomendação de migrar para microsserviços. ‘Cada funcionalidade em um serviço independente, deployados separadamente, escalando de forma autônoma.’ Parece a solução para todos os problemas de escala.

É também uma das formas mais eficazes de criar complexidade desnecessária antes de precisar dela.

A McKinsey documenta: organizações que migraram para microsserviços relatam ganhos de até 30% em performance, mas esse ganho é acompanhado de aumento significativo em complexidade operacional: latência de rede entre serviços, necessidade de orquestração distribuída, dificuldade de debug e rastreamento de transações que cruzam múltiplos serviços.

Para a maioria dos sites em crescimento, um monolito bem estruturado, com separação clara de responsabilidades, banco externo, cache adequado e escala horizontal, aguenta muito mais do que a intuição sugere. Até o Prime Video da Amazon, que atende milhões de usuários, concluiu que para o contexto deles fazia mais sentido retornar a uma arquitetura monolítica.

Microsserviços fazem sentido quando o time cresceu o suficiente para que múltiplos grupos trabalhem em partes diferentes do sistema sem interferir uns nos outros. Não antes. E o monolito modular, com limites claros de responsabilidade dentro de um único processo, é a alternativa que permite crescer sem a complexidade operacional prematura dos microsserviços.

A Forrester aponta que 58% das empresas que adotaram monitoramento avançado reduziram o tempo médio de resposta a incidentes em até 40%. Crescimento sem observabilidade é cego, você descobre os gargalos quando já viraram incidentes.

O que monitorar quando o crescimento começa

As métricas que importam mudam conforme o estágio:

Ferramentas como New Relic, Datadog e a combinação Prometheus + Grafana (self-hosted) permitem construir dashboards que mostram essas métricas em tempo real, com alertas configurados para os thresholds que importam para o seu estágio atual.

Conclusão

Quando um site começa a escalar, ele não cria problemas novos. Ele apenas revela limites que já existiam na arquitetura.

Decisões que pareciam suficientes com algumas centenas de usuários passam a mostrar suas consequências quando o tráfego chega a dezenas de milhares de acessos.

A diferença entre crescer de forma estável e crescer de forma caótica não está em ter uma arquitetura perfeita desde o início, mas em entender os limites do sistema atual e evoluir a infraestrutura antes que o tráfego os force.

Se você está construindo projetos que precisam crescer com previsibilidade, vale também olhar para a base onde tudo está rodando. Infraestruturas modernas com recursos dedicados, armazenamento NVMe e ambientes preparados para workloads web, como as oferecidas pela StayCloud, ajudam a garantir que o crescimento do tráfego não se transforme em um problema técnico.

Quando a infraestrutura acompanha o produto, escalar deixa de ser um risco e passa a ser exatamente o que deveria ser: um sinal de que o projeto está funcionando.