trilha

System Design/04 - Cloud Design Patterns/Design & Implementation2 min

Static Content Hosting

Perguntas-guia
  • Que problema isso resolve?
  • Quando usar / quando NÃO usar?
  • Qual o principal trade-off?
  • Como isso falha em produção?

Conceito

Servir arquivos estáticos — HTML, CSS, JS, imagens, vídeos — a partir de armazenamento de objetos e CDN, e não da aplicação.

aplicação  → só a API dinâmica
S3 + CDN   → todo o conteúdo estático

Trade-offs

O ganho é grande e barato, e vem de três lados ao mesmo tempo:

Custo. Servir bytes de um armazenamento de objetos custa uma fração de servi-los de uma instância de aplicação — que cobra por hora esteja ou não trabalhando.

Escala. Armazenamento e CDN escalam praticamente sem limite, sem provisionamento.

Latência. O conteúdo vem da borda, próximo ao usuário (CDN Caching).

E há um quarto ganho, o mais subestimado: a aplicação deixa de gastar threads e banda com arquivos. Num servidor que serve HTML e API pelo mesmo pool, os arquivos competem com as requisições que realmente exigem lógica.

Os custos são pequenos, mas existem:

Deploy vira duas etapas — publicar os assets e publicar a aplicação —, e a ordem importa: publique os assets antes, senão o HTML novo referencia arquivos que ainda não existem.

Invalidação é o problema de sempre. A solução consagrada evita-o: versionar a URL (app.a3f9c1.js) e usar cache eterno. Publicar significa gerar um nome novo; não há o que invalidar.

Conteúdo privado exige Valet Key — URL assinada com prazo — em vez de deixar o objeto público.

E, para SPAs, a configuração de fallback (404 → index.html) é necessária para que o roteamento do cliente funcione em acesso direto a uma rota.

Exemplo prático

index.html      → S3 + CDN,  Cache-Control: no-cache
app.a3f9c1.js   → S3 + CDN,  max-age=31536000, immutable
imagens/*       → S3 + CDN,  max-age=2592000
/api/*          → aplicação

O index.html revalida a cada visita — é pequeno, e normalmente devolve 304. Todo o peso está nos arquivos versionados, com cache de um ano.

Num deploy, o index.html muda e passa a referenciar app.9d4f2b.js. O cliente busca só o que mudou; o resto vem do cache local. A propagação é imediata e nenhum purge é necessário.

A aplicação, livre dos arquivos, passa a dimensionar apenas para o tráfego de API — que costuma ser uma fração das requisições totais.

Relacionado


Parte de Design & Implementation · roadmap.sh/system-design

Buscar

Busca por título, seção e texto das notas