A CDN é a decisão de escala mais barata que você vai tomar

Quando um produto começa a ficar lento sob carga, o reflexo é adicionar computação. Instâncias maiores, mais réplicas, um tier de banco mais rápido. Isso funciona, e custa dinheiro toda hora para sempre. O movimento mais barato, e o primeiro que checo em toda revisão de performance, é perguntar quantas das requisições que chegam na origem nunca deveriam ter chegado lá.

Para a maioria dos produtos web, a resposta é a maioria delas. Assets estáticos, páginas públicas, listagens de produto, documentação, imagens, respostas de API que mudam uma vez por hora. Tudo isso pode ser servido de um nó de borda perto do usuário, e quando é, a origem vê uma fração do tráfego e o usuário vê uma fração da latência.

O que uma CDN realmente compra

Três coisas, e são separadas. Primeiro, distância: um nó de borda a poucos milissegundos do usuário em vez de uma origem em outro continente. Para uma página com uma dúzia de assets, é a diferença entre um segundo e um quinto de segundo antes de qualquer coisa renderizar. Segundo, alívio: cada cache hit é uma requisição que a origem não serve, o que significa menos instâncias, menos conexões de banco e um raio de explosão menor quando a origem tem um dia ruim. Terceiro, absorção: um pico de tráfego, seja lançamento ou ataque, bate primeiro na borda, e a borda foi feita para aguentar.

A conta de tudo isso costuma ser uma fração da computação que substitui, e em muitas plataformas os primeiros terabytes são de graça. É difícil encontrar retorno melhor em infraestrutura.

A parte que as pessoas erram

CDN é trivial para arquivo estático. O valor, e o risco, está em cachear resposta dinâmica, e isso se resume a headers. Uma resposta sem header de cache é tratada com conservadorismo, o que significa que a CDN não faz nada. Uma resposta com max-age longo e dados privados de um usuário dentro é um vazamento de dados servido na velocidade da luz.

Então a disciplina é por rota. Pública e de mudança lenta: cacheia na borda com max-age de minutos a horas, e adiciona uma janela de stale-while-revalidate para o usuário nunca esperar refresh. Pública e de mudança rápida: max-age curto, de segundos a um minuto, que ainda absorve um pico. Personalizada: sem cache de borda, nunca, marcada como private, e a CDN ainda deve terminar TLS e comprimir. O erro que mais encontro é cookie ou header de authorization que varia a resposta sem estar declarado, então a página cacheada de um usuário é servida para outro. Header Vary existe para isso, e não é opcional.

Invalidação, com honestidade

Invalidação de cache é famosa por ser difícil. É menos difícil se as chaves de cache são escolhidas com cuidado. Assets recebem hash de conteúdo no nome do arquivo e max-age de um ano, então nunca são invalidados, só substituídos. Páginas recebem max-age curto e uma tag, então uma mudança de conteúdo pode purgar tudo com aquela tag numa chamada só. Respostas de API recebem ETag para a CDN revalidar barato em vez de buscar de novo.

O que não funciona é 'purga tudo no deploy'. Funciona tecnicamente e joga fora o benefício inteiro no momento de maior risco, quando uma versão nova está subindo sob tráfego cheio.

O checklist que eu rodo

• Todo asset tem hash de conteúdo no path e max-age de um ano.
• Toda rota pública declara uma política de cache explícita; nenhuma rota depende de default.
• Toda rota personalizada é marcada como private e nunca varia silenciosamente por cookie.
• A taxa de cache hit é medida, e qualquer coisa abaixo de oitenta por cento em tráfego público é investigada.
• Purga é por tag ou path, testada em staging, e nunca 'tudo'.

Rode esse checklist num produto que nunca teve CDN na frente, e o tráfego na origem geralmente cai mais da metade. Isso é escala pela qual você não pagou computação, e está disponível antes de a primeira instância maior ser encomendada.