Como escalar sistema para 1 milhão de usuários: guia passo a passo

Escalar sistema para 1 milhão de usuários exige cinco peças: load balancer, cluster de servidores, banco com réplicas de leitura, cache e CDN. Com processamentos pesados, entra uma fila de jobs com workers. Múltiplos data centers só entram se você precisar de alcance global. Entenda o papel de cada peça a seguir.

O caminho para escalar sistema para 1 milhão de usuários

Para escalar sistema para 1 milhão de usuários, você evolui a arquitetura em estágios. Cada estágio resolve um gargalo e elimina um ponto único de falha (SPOF, do inglês single point of failure). O roteiro segue a lógica do livro System Design Interview, de Alex Xu, publicado em 2020, que estrutura exatamente essa progressão em entrevistas técnicas. A aula que originou este artigo faz parte de um curso com mais de 90 aulas de system design disponíveis no YouTube.

A regra geral é simples: você não começa com a arquitetura final. Você começa com o mínimo que funciona e adiciona complexidade só quando a demanda aparece. Em uma entrevista de system design, mostrar que você conhece essa ordem e o motivo de cada peça vale mais do que desenhar dez caixas aleatórias no quadro.

O roteiro completo tem sete passos, sempre nesta ordem:

1. Servidor único com banco SQL.
2. Load balancer na frente de um cluster de servidores.
3. Réplicas de leitura no banco de dados.
4. Cache na frente do banco.
5. CDN para arquivos estáticos.
6. Filas com workers para processamento pesado.
7. Múltiplos data centers, só se houver requisito global.

Qual é o ponto de partida: servidor e banco de dados

O sistema mínimo é um usuário com browser ou aplicativo mobile fazendo requisições para um web server que roda a aplicação. Para dar durabilidade aos dados, quase toda aplicação adiciona um banco de dados, porque o servidor pode cair ou reiniciar e a informação não pode morrer junto com ele.

A primeira decisão é SQL ou NoSQL. A convenção é começar com SQL tradicional, e desviar dela só quando você souber argumentar o porquê. A pergunta certa não é qual banco é melhor no abstrato, e sim qual atende a carga de trabalho do seu problema.

Porque SQL é o padrão e quando NoSQL ganha

Na maioria das aplicações, SQL é a escolha adequada: consistência forte, ferramental maduro e décadas de uso em produção. NoSQL tende a ser a escolha certa em três situações específicas:

Critério	Fique com SQL	Considere NoSQL
Latência	Consultas relacionais complexas	Cada milissegundo de resposta importa
Esquema	Dados relacionais estáveis	Logs, JSON e dados que mudam de forma com frequência
Throughput	Volume moderado de escritas	Enormes volumes em janelas curtas, como guardar todos os requests recebidos

Se o seu caso concreto se encaixa nas três situações da coluna da direita, defender NoSQL em uma entrevista não é problema nenhum, desde que você justifique com o comportamento da sua carga de trabalho.

Por que um servidor único não escala

Aumentar o tamanho da máquina (escala vertical) funciona até um limite físico e deixa o servidor como um ponto único de falha: se ele cai, a aplicação inteira cai. Nenhuma aplicação do porte de uma Netflix roda em um servidor único exatamente por isso.

A solução é rodar a aplicação em vários servidores que leem e escrevem no mesmo banco de dados. Como os dados já estão persistidos fora do servidor, adicionar máquinas é seguro. O usuário, porém, precisa saber para qual servidor enviar cada requisição, e é aí que entra o balanceador de carga.

O que um load balancer resolve

O load balancer é o componente que direciona cada requisição para um dos servidores do cluster. Ele aumenta a vazão do serviço, reduz a chance de queda total e permite discutir diferentes estratégias de redirecionamento, como round-robin ou roteamento por geolocalização mais adiante. O Nginx, software de código aberto lançado em 2004, é um exemplo clássico de tecnologia que exerce esse papel em produção.

Com o cluster no lugar, o servidor deixa de ser o gargalo e o ponto único de falha migra para o banco de dados. Essa é a progressão natural de uma entrevista: resolva um gargalo e identifique o próximo.

Como escalar o banco de dados com replicação

A primeira forma de escalar o banco costuma ser replicação no padrão primário-réplicas: você escreve em um banco e mantém réplicas apenas para leitura. Como a maioria das aplicações lê muito mais do que escreve, essa divisão aumenta a vazão sem sacrificar a consistência das escritas. A escrita é replicada nas réplicas, e as leituras saem delas.

E o que acontece se o banco de escrita cair ou for corrompido? Como todas as réplicas compartilham dos mesmos dados, você promove uma delas a banco de escrita. O risco que a replicação introduz é inconsistência: escrever simultaneamente em dois bancos pode gerar race conditions, e é por isso que a escrita fica concentrada em um nó por vez.

Cache: velocidade com uma condição

Mesmo com réplicas, consultas a banco custam tempo por causa da rede e das buscas. Um cache na frente do banco acelera o serviço: os servidores consultam o cache primeiro e só vão ao banco quando a informação não está lá. O Redis, criado em 2009, é a implementação mais usada para esse papel e responde consultas em memória, na casa de submilissegundos.

O detalhe que decide a entrevista: o cache também pode ser um ponto único de falha. A aplicação precisa de uma boa política de invalidação e precisa funcionar quando o cache não responde ou simplesmente não existe. Um cache que derruba o sistema quando cai está desenhado errado.

CDN, estado e filas: os ajustes finos

Três peças completam o desenho antes da expansão global. Elas atacam gargalos diferentes, e cada uma tem uma regra de decisão própria.

CDN para arquivos estáticos

Filmes, fotos, logos e páginas HTML mudam raramente e podem pesar muito na rede. Servi-los por meio de uma CDN (content delivery network, rede de entrega de conteúdo), como fazem as CDNs da Cloudflare, alivia a carga do serviço e reduz a latência percebida: a página inicial chega muito mais rápido vinda da CDN do que do seu servidor de origem.

Servidores sem estado e sessões

O cluster de backend precisa ser sem estado. Se o estado de login de um usuário ficar num servidor específico e a próxima requisição dele cair em outro, ele aparece deslogado. Sessões e preferências que exigem aderência (sticky sessions) ficam melhor em um NoSQL auxiliar, fora dos servidores web, porque servidores podem ser desativados a qualquer momento para ajustar a capacidade.

Filas e workers para processamento pesado

Processamento de vídeo, imagens e geração de PDF não devem bloquear o servidor web. O padrão é publisher-subscriber: a aplicação publica jobs numa fila, e workers, rodando em máquinas separadas, consomem essa fila em sequência. Os servidores web continuam leves e rápidos para responder o usuário enquanto o trabalho pesado acontece em paralelo.

Vale também representar no desenho os serviços de tooling: observabilidade, métricas, monitoramento, health checks e logs de erro. Eles não aparecem em todo diagrama, mas qualquer sistema em produção séria os tem rodando fora dos servidores de aplicação.

Múltiplos data centers: quando faz sentido

A última etapa é distribuir o conjunto inteiro, cluster, cache e banco, por regiões. No exemplo clássico da AWS, você teria um data center no US East 1 (virginia, nos Estados Unidos) e outro no EU Central 1 (frankfurt, na Europa), com um load balancer fazendo roteamento por geolocalização para enviar cada usuário à região mais próxima. A exceção é o NoSQL de sticky sessions, que costuma ser compartilhado entre as regiões.

A ressalva honesta: mesmo sem múltiplos data centers, a arquitetura descrita até aqui provavelmente já atende 1 milhão de usuários. A expansão global adiciona complexidade real, e você só a adota quando a diversificação geográfica é um requisito do negócio, não um enfeite de diagrama.

Perguntas frequentes sobre escalabilidade

Por que começar com SQL e não com NoSQL?

Porque SQL atende à maioria das aplicações com consistência e ferramental maduro. NoSQL ganha quando você precisa de latência muito baixa, esquema flexível ou throughput altíssimo, e você deve saber argumentar esse encaixe antes de escolher.

O que é um single point of failure?

É qualquer componente cuja falha derruba a aplicação inteira. No caminho de escalabilidade, o servidor único é o primeiro SPOF, o banco de escrita é o segundo, e réplicas e clusters existem para eliminar cada um deles.

Cache não é um risco adicional?

É, se desenhado sem salvaguardas. A aplicação precisa de política de invalidação e precisa continuar funcionando quando o cache cai ou não responde. Cache acelera, mas nunca pode virar dependência obrigatória para o sistema responder.

Preciso de múltiplos data centers para 1 milhão de usuários?

Provavelmente não. A combinação de load balancer, cluster de servidores, replicação, cache e CDN já sustenta esse volume. Múltiplas regiões entram quando há requisito de alcance global e latência entre continentes.

O que são sticky sessions?

São sessões persistentes, em que o estado de login e as preferências do usuário ficam amarrados a um servidor específico. O problema é que servidores sobem e caem o tempo todo, então o recomendado é guardar esse estado em um NoSQL auxiliar, fora do cluster web.

Para que serve uma fila de jobs?

Para tirar o processamento pesado do caminho da requisição do usuário. A aplicação publica o trabalho numa fila, o worker consome em sequência em outra máquina, e o servidor web continua livre para responder rápido.

Qual é a diferença entre escala vertical e horizontal?

Escala vertical é aumentar a máquina: mais CPU, mais memória. Ela tem limite físico e mantém o ponto único de falha. Escala horizontal é adicionar máquinas ao cluster, e é o caminho que sustenta 1 milhão de usuários.

Onde a CDN entra no desenho?

Na frente de tudo que é estático: vídeos, fotos, logos e páginas HTML. O usuário busca esses arquivos direto na CDN, o que alivia sua rede e faz a primeira página carregar mais rápido.

Esse desenho serve para entrevista de system design?

Serve como esqueleto. A progressão servidor único, load balancer, réplicas, cache, CDN, filas e data centers cobre o ferramental básico que entrevistas esperam; o diferencial está em justificar cada peça com a carga de trabalho do problema proposto.

Do vídeo ao artigo: transforme sua aula em conteúdo

A aula que originou este artigo segue a mesma lógica da arquitetura que ela ensina: partir do simples e adicionar camadas até o conteúdo ficar completo. Se você gravou aulas, entrevistas ou explicações técnicas em vídeo e elas merecem alcance maior, esse conhecimento pode virar um artigo estruturado e pesquisável.

O Skala Blog faz exatamente essa conversão: você cola a URL do vídeo do YouTube, o conteúdo é transcrito e vira um artigo pronto para revisar e publicar. Vale para qualquer creator que já tem o conhecimento gravado e só falta colocá-lo por escrito.

Source video