Push CDNs

Conceito

Você envia o conteúdo para a CDN quando ele é criado ou alterado. A borda nunca busca na origem — ela já tem tudo.

publicação → upload para a CDN → replica entre as bordas
usuário    → borda (sempre HIT)

Na prática moderna, isso costuma significar hospedar o conteúdo num armazenamento de objetos e colocar a CDN na frente, ou usar a API de pré-carregamento da CDN.

Trade-offs

O ganho é não existir cold miss: o primeiro usuário é tão rápido quanto o milésimo, e a origem pode até estar desligada. Para um lançamento com pico previsto, isso elimina o cache stampede que o modelo pull sofre (ver Pull CDNs).

Os custos são três:

1. Armazenamento pago por tudo — inclusive o conteúdo que ninguém acessa. Com 500 mil arquivos e 2% de acesso real, você paga 100% para servir 2%.
2. Publicação vira parte do deploy — se o passo de push falha, o conteúdo não existe na borda. É mais uma etapa que pode quebrar.
3. Propagação não é instantânea — replicar entre bordas leva tempo, e durante ele diferentes usuários veem versões diferentes.

Por isso o modelo push perdeu espaço: para a maioria dos casos, pull com boa política de cache entrega quase o mesmo resultado com muito menos operação. Push continua fazendo sentido quando o catálogo é pequeno, previsível e crítico no primeiro acesso.

Exemplo prático

Um jogo distribui um patch de 2 GB para milhões de jogadores numa data marcada.

Com pull, no minuto do lançamento, centenas de bordas fazem miss simultâneo e puxam 2 GB cada da origem — a origem satura antes de qualquer usuário ser atendido.

Com push, o arquivo é pré-carregado nas bordas horas antes. No horário do lançamento, todo pedido é HIT, a origem não recebe nada, e o pico é absorvido pela capacidade agregada da CDN.

O critério que decide: um arquivo, acesso previsível e concentrado, custo de miss altíssimo. Inverta qualquer um dos três e pull volta a ser melhor.

Relacionado

• Pull CDNs

---

Parte de Content Delivery Networks · roadmap.sh/system-design