DNS e CDN

Às 10:00 abre a venda do show no estádio do BoxOffice e 2 milhões de celulares fazem as mesmas duas perguntas quase ao mesmo tempo: "onde fica boxoffice.com?" e "me dê a página do evento". Se as duas perguntas viajarem até os servidores do BoxOffice em São Paulo, os servidores se afogam antes de um único assento ser vendido. O Domain Name System (DNS) e uma Content Delivery Network (CDN) existem para que a maioria dessas perguntas seja respondida perto do fã, por máquinas que o BoxOffice nem opera.

Esta página cobre os dois primeiros saltos da jornada da requisição: o DNS decide para onde um cliente vai; a CDN decide se a requisição precisa ir mais longe.

DNS: a lista telefônica da Internet

Computadores falam com endereços IP (203.0.113.10, 2001:db8::10); pessoas digitam nomes (boxoffice.com). O DNS traduz o nome em endereços. É um dos sistemas distribuídos mais antigos e maiores que existem: um banco de dados hierárquico, delegado e fortemente cacheado¹.

• Hierárquico: os nomes são lidos da direita para a esquerda. A raiz (.) sabe quem é responsável por com.; com. sabe quem é responsável por boxoffice.com.; boxoffice.com. sabe o endereço de api.boxoffice.com.
• Delegado: cada nível é operado por uma organização diferente. O BoxOffice controla só a própria zona, boxoffice.com, por meio dos seus servidores de nomes autoritativos (normalmente um serviço gerenciado como Route 53 ou Cloudflare DNS).
• Cacheado: toda resposta carrega um TTL (time to live, em segundos). Os resolvers guardam a resposta por esse tempo, de modo que a imensa maioria das consultas nunca chega aos servidores autoritativos.

Resolução, passo a passo

Quando o celular do fã precisa de api.boxoffice.com, ele não percorre a hierarquia sozinho. Um pequeno stub resolver no sistema operacional pergunta a um resolver recursivo (o da operadora de celular, ou um público como 1.1.1.1 ou 8.8.8.8), que faz o trabalho e guarda os resultados em cache:

sequenceDiagram
    participant P as Celular (stub resolver)
    participant R as Resolver recursivo
    participant Root as Servidor raiz
    participant TLD as Servidor do TLD .com
    participant A as Autoritativo de boxoffice.com
    P->>R: A? api.boxoffice.com
    Note over R: cache miss
    R->>Root: A? api.boxoffice.com
    Root-->>R: pergunte a .com (NS a.gtld-servers.net)
    R->>TLD: A? api.boxoffice.com
    TLD-->>R: pergunte a boxoffice.com (NS ns1.boxoffice-dns.net)
    R->>A: A? api.boxoffice.com
    A-->>R: 203.0.113.10, TTL 60
    Note over R: guarda em cache por 60 s
    R-->>P: 203.0.113.10
    P->>R: A? api.boxoffice.com (outro fã, 5 s depois)
    R-->>P: 203.0.113.10 (do cache)

Uma consulta a frio custa várias idas e voltas (dezenas a centenas de milissegundos); uma em cache custa uma única ida e volta até o resolver, ou nada, quando a resposta está no cache do sistema operacional ou do navegador. Na prática, as respostas da raiz e de .com também quase sempre estão em cache (os TTLs delas são de um a dois dias), então um miss típico custa só uma viagem do resolver até o servidor autoritativo.

Tipos de registro

TTL: atualidade versus carga

O TTL é um trade-off clássico entre a rapidez com que uma mudança se propaga e quanta carga e latência as consultas custam:

Roteamento com DNS: GeoDNS, latência, pesos e failover

Como é o servidor autoritativo que escolhe a resposta, ele pode dar respostas diferentes para clientes diferentes. Serviços de DNS gerenciados oferecem várias políticas de roteamento⁴:

O failover por DNS é a forma mais simples de recuperação de desastres multirregião: o provedor de DNS sonda https://sa.boxoffice.com/health a cada 10–30 s a partir de vários locais; depois de algumas falhas, ele para de devolver o endereço da primária e devolve o da secundária.

sequenceDiagram
    participant HC as Health checker do DNS
    participant P as Região SP (primária)
    participant S as Região US (secundária)
    participant F as Resolver do fã
    HC->>P: GET /health
    P-->>HC: 200 OK
    F->>HC: A? api.boxoffice.com
    HC-->>F: endereço de SP (TTL 60)
    Note over P: queda da região
    HC->>P: GET /health
    Note over HC: 3 falhas seguidas: marca SP como não saudável
    F->>HC: A? api.boxoffice.com (depois que o TTL expirou)
    HC-->>F: endereço de US (TTL 60)
    F->>S: o tráfego agora vai para a secundária

Experimente. Abra o cenário multirregião e rode o perfil load. Depois provoque a queda da região primária (chaos high, ou desative a região no painel). Observe quanto tempo os erros duram até o DNS mandar o tráfego para a secundária, e mude o TTL do DNS para ver como ele estica ou encurta essa janela.

Abrir o playground completo

Anycast

Com o endereçamento comum (unicast), um endereço IP pertence a um lugar. Com anycast, o mesmo endereço IP é anunciado via BGP (o Border Gateway Protocol, que cola as redes da Internet umas às outras) a partir de vários locais ao mesmo tempo, e cada pacote é entregue pela rede ao local mais próximo, em termos de roteamento.

flowchart LR
    f1([Fã em São Paulo]) --> sp["Borda São Paulo<br/>anuncia 198.51.100.1"]
    f2([Fã em Lisboa]) --> li["Borda Lisboa<br/>anuncia 198.51.100.1"]
    f3([Fã em Tóquio]) --> tk["Borda Tóquio<br/>anuncia 198.51.100.1"]

O anycast dá três coisas de uma vez, sem nenhum truque de DNS:

• Baixa latência: todo cliente chega a um local próximo.
• Failover automático: se um local para de anunciar o endereço, o roteamento converge para o próximo mais perto, tipicamente em segundos.
• Absorção de DDoS: um ataque de uma botnet global é dividido entre todos os locais em vez de atingir um só (veja segurança na borda).

Os servidores DNS raiz, resolvers públicos como 1.1.1.1 e 8.8.8.8, e toda grande CDN usam anycast. O anycast funciona melhor com trocas curtas e quase sem estado (DNS sobre UDP, requisições HTTP a um cache de borda); uma mudança de rota no meio de uma conexão TCP longa pode quebrá-la, o que os grandes provedores mitigam com um roteamento cuidadoso.

CDN: leve o conteúdo até o fã

Uma CDN é uma rede de proxies reversos com cache — pontos de presença (PoPs), centenas deles pelo mundo — que guardam cópias do seu conteúdo perto dos usuários³. Um fã em Recife que pede o logo do BoxOffice o recebe de um PoP em Recife ou Fortaleza, não da origem em São Paulo; um fã em Lisboa o recebe de Lisboa, não do outro lado do Atlântico.

Uma CDN faz três trabalhos ao mesmo tempo⁵:

1. Latência: o conteúdo viaja alguns quilômetros em vez de milhares. Uma ida e volta atravessando o Atlântico custa cerca de 100–150 ms; até um PoP na mesma cidade, alguns milissegundos.
2. Alívio da origem: cada cache hit é uma requisição que a origem (seus servidores) nunca vê. Muitas vezes esse é o principal motivo para uma CDN em um system design.
3. Proteção: a capacidade e a rede anycast da CDN absorvem picos de tráfego e ataques antes que cheguem até você.

sequenceDiagram
    participant F1 as Fã 1 (Recife)
    participant E as PoP da CDN em Recife
    participant O as Origem (São Paulo)
    participant F2 as Fã 2 (Recife)
    F1->>E: GET /img/stadium.webp
    Note over E: MISS: não está no cache
    E->>O: GET /img/stadium.webp
    O-->>E: 200, Cache-Control: max-age=86400
    E-->>F1: 200 (guardado por 1 dia)
    F2->>E: GET /img/stadium.webp
    Note over E: HIT
    E-->>F2: 200 do PoP (origem intocada)

Pull versus push

A maioria dos designs usa pull na frente de uma origem, e essa origem frequentemente é um object store (S3, Cloud Storage, Azure Blob — o componente objstore) para arquivos estáticos e mídia.

A chave de cache

A CDN guarda cada resposta sob uma chave de cache — por padrão, o host mais o caminho da URL mais a query string. Duas requisições com a mesma chave compartilham a cópia em cache. Acertar a chave é a maior parte do trabalho:

• Uma chave específica demais fragmenta o cache: /events/42?utm_source=instagram e /events/42?utm_source=email são a mesma página, mas com a chave padrão são guardadas duas vezes e as duas dão miss. Remova parâmetros de rastreamento da chave, ou ordene os parâmetros da query.
• Uma chave genérica demais vaza dados: se a resposta depende de um cookie (session=…) ou de um header (Accept-Language) que não está na chave, um fã pode receber uma página personalizada para outro.
• O header de resposta Vary diz aos caches quais headers da requisição mudam a resposta (Vary: Accept-Encoding é normal; Vary: Cookie na prática desativa o cache compartilhado).

Cache-Control: a origem decide

A origem diz a todo cache — o navegador, a CDN, qualquer proxy no meio — o que ele pode fazer com uma resposta por meio do header Cache-Control²:

A revalidação usa validadores: a origem envia um ETag (um identificador de versão) ou Last-Modified; o cache pergunta If-None-Match: "v42", e a origem responde 304 Not Modified sem corpo quando nada mudou — barato para os dois lados.

# fingerprinted JavaScript bundle: cache "forever"
Cache-Control: public, max-age=31536000, immutable

# event page HTML: short in browsers, longer at the CDN, survive origin hiccups
Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60, stale-if-error=3600

# seat availability JSON during the sale: micro-cache at the CDN for one second
Cache-Control: public, max-age=0, s-maxage=1, stale-while-revalidate=1

# the fan's order and payment pages: never cache
Cache-Control: private, no-store

Invalidação: purgar ou versionar?

A imagem do pôster do evento mudou. Como os 300 PoPs ficam sabendo? Há duas estratégias:

• Purge (invalidação): chame a API da CDN para remover /img/stadium.webp (ou uma tag, ou um prefixo) de todos os PoPs. A próxima requisição dá miss e busca a nova versão. Purges não são instantâneos — eles se propagam em segundos a minutos, dependendo do provedor — e navegadores que já guardaram a versão antiga com max-age não serão purgados de jeito nenhum.
• URLs versionadas (com fingerprint): nunca altere um arquivo no lugar. O build produz app.3f9a1c.js; um novo build produz app.b71e02.js e o HTML referencia o novo nome. Versões antigas e novas coexistem, os caches nunca servem a errada, e os arquivos podem ficar em cache com immutable por um ano. Só o pequeno HTML que os referencia precisa de um TTL curto.

Prefira URLs versionadas para todo arquivo estático e reserve os purges para casos excepcionais (um erro em uma página publicada, remoções por ordem judicial). É a versão de borda da piada mais antiga da computação — só existem duas coisas difíceis em ciência da computação: invalidação de cache e dar nomes às coisas — e as URLs versionadas resolvem a primeira fazendo a segunda. A invalidação em geral é estudada na aula de caching.

Origin shield e cache em camadas

Com 300 PoPs, um arquivo novo pode causar 300 misses — um por PoP — que vão todos para a origem. Um cache em camadas (tiered cache, ou origin shield) acrescenta uma camada intermediária: os PoPs perguntam a um cache regional, e só o cache regional pergunta à origem. A origem vê uma requisição por objeto em vez de uma por PoP, e o request collapsing no shield junta misses simultâneos para o mesmo objeto em uma única busca na origem.

flowchart LR
    p1[PoP Recife] --> sh[Origin shield<br/>São Paulo]
    p2[PoP Porto Alegre] --> sh
    p3[PoP Manaus] --> sh
    sh --> o[(Origem)]

Quanto importa a taxa de acerto?

A fração das requisições que a CDN atende a partir do cache é a taxa de acerto (hit ratio). A carga na origem é a fração de miss vezes o tráfego, então cada "nove" a mais na taxa de acerto divide a carga da origem por dez. Suponha (premissa ilustrativa) que 200.000 requisições por segundo cheguem à borda durante a venda:

Ir de 90% para 99% de taxa de acerto parece uma melhora pequena ("só nove pontos"), mas corta a carga da origem de 20.000 para 2.000 requisições por segundo — dez vezes menos servidores. Quando discutir uma CDN em uma entrevista, fale da taxa de miss, não da taxa de acerto: é o número que dimensiona a origem.

Experimente. Carregue o cenário de CDN e rode o perfil load. Baixe a taxa de acerto da CDN (ou o TTL) passo a passo e observe a taxa de requisições e a latência p99 nos app servers crescerem; depois suba-a e veja de quão poucas réplicas da aplicação você precisa. Por fim, purgue o cache durante a execução: a onda repentina de misses é um stampede em pequena escala sobre a origem.

Abrir o playground completo

Cache de conteúdo dinâmico: micro-caching

"Dinâmico" não quer dizer "impossível de cachear". O JSON de disponibilidade de assentos do show no estádio muda o tempo todo, mas ninguém é prejudicado se ele tiver um segundo de idade. Se cada PoP o guarda por 1 s (s-maxage=1), a origem recebe no máximo uma requisição por segundo por PoP (ou por shield, com cache em camadas), não importa quantos fãs estejam fazendo polling. Com 2 milhões de fãs fazendo polling a cada 5 segundos — 400.000 requisições por segundo — e 50 PoPs atendendo o Brasil, a origem vê cerca de 50 requisições por segundo para esse endpoint. O mapa de assentos fica no máximo um segundo desatualizado; a reserva em si (POST /api/holds) nunca é cacheada e é verificada contra o banco de dados, então um mapa desatualizado nunca causa uma venda em dobro.

Edge compute

CDNs modernas também executam o seu código nos PoPs: Cloudflare Workers, AWS CloudFront Functions e Lambda@Edge, Fastly Compute, Akamai EdgeWorkers. São funções pequenas (milissegundos de CPU, memória limitada, normalmente JavaScript ou WebAssembly) executadas a cada requisição, antes do cache ou da origem. Bons usos:

• Validar um token de sala de espera ou a assinatura de um JWT na borda e rejeitar requisições inválidas antes que atravessem o oceano.
• Reescrever e redirecionar: testes A/B, redirecionamentos por idioma, normalizar a chave de cache (removendo os parâmetros utm_*).
• Montar respostas a partir de fragmentos em cache, ou acrescentar headers de segurança.
• Servir uma página de sala de espera inteiramente a partir da borda enquanto a origem é protegida.

Maus usos: qualquer coisa que precise do seu banco de dados a cada requisição (a função está longe dos dados, então cada chamada atravessa a rede de qualquer jeito), computações longas e lógica de negócio que seria mais bem testada e versionada em um serviço.

Trade-offs em resumo

Como se conecta

flowchart LR
    TTL["TTL do DNS"] --> FO["velocidade do failover<br/>→ multirregião (aula 3)"]
    ANY["anycast"] --> DDOS["absorção de DDoS<br/>→ segurança na borda"]
    GEO["GeoDNS / roteamento por latência"] --> HOME["região de origem por evento<br/>→ CAP e PACELC"]
    HIT["taxa de acerto da CDN"] --> ORIGIN["carga na origem<br/>→ Estimativas"]
    CC["Cache-Control, TTL"] --> STALE["dado desatualizado = consistência eventual<br/>→ Replicação e Consistência"]
    INV["invalidação, URLs versionadas"] --> CACHE["invalidação de cache<br/>→ Caching"]
    EC["edge compute"] --> WR["verificação do token da sala de espera<br/>→ API gateway"]

Componentes da paleta: dns · cdn · objstore (a origem usual da CDN para imagens e vídeo) · cache (a próxima camada de cache atrás da CDN). Cenários: cdn-static, multi-region, video-streaming. Continua em: Caching — padrões, Sistemas Distribuídos — CAP e PACELC, Estudo de caso: streaming de vídeo.

Pontos-chave