Uma arquitetura simples, em três peças

Lógica, banco de dados e CDN: como separar quem decide, onde os dados vivem e como os arquivos grandes chegam ao usuário.

Quase todo site ou aplicativo pode ser descrito com três peças, cada uma com um trabalho diferente. Separar essas responsabilidades facilita entender onde está cada problema, crescer quando o tráfego aumenta e trocar uma tecnologia sem refazer o resto.

EXEC: a parte que tem a lógica e manipula os dados. Recebe pedidos, aplica regras e responde.
Database: os dados dinâmicos, que mudam a todo momento, como saldos, pedidos e mensagens.
CDN: os dados grandes e estáticos, que quase nunca mudam, como imagens, vídeos e arquivos de código.

EXEC: onde a lógica vive

O EXEC pode ser escrito em qualquer linguagem: Python, Go, JavaScript, Java, C# ou outra. A escolha depende do time e do problema, mas o papel é sempre o mesmo. Ele recebe uma requisição, decide o que fazer, lê ou grava no banco e devolve uma resposta.

Uma boa prática é não guardar estado na memória do EXEC entre uma requisição e outra. Assim, dá para rodar várias cópias atrás de um balanceador, e qualquer uma delas atende qualquer pedido. Sessões e caches ficam fora, no banco ou em outro serviço.

Database: dados que mudam o tempo todo

Saldos, pedidos, carrinhos e sessões precisam estar sempre atualizados e corretos. Por isso o banco é a fonte da verdade do sistema. Quando algo precisa acontecer por inteiro ou não acontecer, o banco oferece transações: uma transferência debita uma conta e credita outra, ou as duas operações acontecem, ou nenhuma delas.

CDN: dados grandes que quase nunca mudam

Imagens, vídeos, bibliotecas de JavaScript e CSS, fontes e downloads são grandes e não mudam com frequência. Uma CDN, ou rede de entrega de conteúdo, copia esses arquivos para servidores espalhados pelo mundo e entrega cada um do ponto mais próximo de quem pede. Assim, o EXEC e o banco não gastam tempo nem banda com arquivos que poderiam estar em outro lugar.

Uma técnica útil é colocar um hash do conteúdo no nome do arquivo, como app.3f9a1c.js. Se o conteúdo muda, o nome muda, e a CDN e o navegador podem guardar a versão antiga para sempre sem risco de servir algo errado.

O caminho de cada pedido

Escolha um tipo de pedido abaixo e veja, passo a passo, quais peças participam.

Escolha um tipo de pedido para ver o caminho que ele percorre.

Regras práticas

Arquivo grande nunca passa pelo EXEC. Ele vai direto para a CDN.
O EXEC não guarda estado em memória. Quanto mais sem estado, mais fácil escalar.
O banco é a fonte da verdade. Qualquer cache pode ser refeito a partir dele.
Arquivos da CDN recebem nomes com o hash do conteúdo, para que o cache nunca fique desatualizado.

Um exemplo em pseudocódigo

GET /saldo              (EXEC)
  usuario = autenticar(requisicao)
  saldo   = banco.consultar("SELECT valor FROM contas WHERE id = ?", usuario.id)
  responder(saldo)

GET /videos/aula-03.mp4 (CDN, o EXEC não participa)

Quando isso não basta

Com muito tráfego, entram réplicas de banco, filas para tarefas demoradas e caches de leitura. Mesmo assim, o desenho continua o mesmo: a lógica responde aos pedidos, o banco guarda o que muda e a CDN entrega o que é grande e estável.