---
term: 'CDN (Content Delivery Network)'
seoTitle: 'O que é uma CDN (Content Delivery Network)? Guia Completo'
headline: 'O que é uma CDN?'
slug: cdn
category: cloud-architecture
shortDefinition: 'Uma CDN é uma rede de servidores distribuídos que mantém conteúdo em cache perto dos usuários, para páginas e arquivos carregarem rápido em qualquer lugar.'
relatedTerms:
  - edge-computing-edge-functions
  - ssr-vs-csr-vs-ssg
  - jamstack
  - api-payload-optimization
contrastsWith:
  - edge-computing-edge-functions
faq:
  - question: 'O que é uma CDN em termos simples?'
    answer: 'Uma rede de servidores distribuída geograficamente que mantém cópias em cache do seu conteúdo perto dos seus usuários. Em vez de cada requisição viajar até o servidor de origem — possivelmente do outro lado do oceano — a maioria é respondida em milissegundos por um servidor de edge próximo. A maior parte do tráfego web dos grandes sites é servida assim.'
  - question: 'Como funciona uma CDN?'
    answer: 'Roteamento mais cache. A requisição do usuário é direcionada ao ponto de presença mais próximo; se aquele servidor de edge tem uma cópia fresca em cache (um cache hit), ele responde imediatamente. Se não tem (um miss), o edge busca na origem, guarda uma cópia pelo TTL que você configurou e serve todo mundo por perto a partir do cache até ela expirar.'
  - question: 'CDN é a mesma coisa que hospedagem de site?'
    answer: 'Não — a CDN complementa a hospedagem, nunca a substitui. Seu host (a origem) armazena o conteúdo autoritativo; a CDN mantém cópias temporárias no edge. Se a origem desaparece, em algum momento a CDN fica sem nada para servir. A divisão de trabalho: a origem é a fonte da verdade, a CDN é a camada de distribuição.'
  - question: 'O que são cache hit, cache miss e TTL?'
    answer: 'Hit significa que o edge serviu sua cópia em cache — rápido, e a origem nem ficou sabendo. Miss significa que o edge não tinha cópia fresca e buscou na origem — mais lento, uma vez, para o primeiro visitante da região. TTL (time to live) é por quanto tempo uma cópia em cache conta como fresca, definido via headers Cache-Control. Projetar cache é, em boa parte, a arte de maximizar hits sem servir conteúdo velho.'
  - question: 'Uma CDN consegue servir conteúdo dinâmico?'
    answer: 'Não a partir do cache, no sentido clássico — uma resposta de API personalizada difere por usuário. Mas CDNs ainda aceleram tráfego dinâmico com rotas otimizadas, conexões persistentes e TLS terminado perto do usuário; e plataformas modernas executam lógica no próprio edge. A divisão prática: cacheie assets estáticos agressivamente, acelere respostas dinâmicas e compute no edge onde compensa.'
  - question: 'Como uma CDN protege contra ataques DDoS?'
    answer: 'Sendo enorme e estando no caminho. Como reverse proxy, a CDN esconde o endereço da sua origem, e sua capacidade distribuída absorve ataques volumétricos por muitos pontos de presença — o tráfego que achataria um único servidor se dissipa por uma rede global, com filtragem aplicada no edge antes de qualquer coisa chegar até você.'
  - question: 'Quando você NÃO precisa de uma CDN?'
    answer: 'Quando sua audiência é local à região do seu servidor, um salto extra por um edge distante pode até adicionar latência; quando o tráfego é tão baixo que o cache expira entre um visitante e outro (misses perpétuos não ajudam em nada); e quando um app pequeno e dinâmico simplesmente não é limitado pela entrega. CDN é alavanca sobre distância e volume — sem nenhum dos dois, é configuração sem benefício.'
  - question: 'Qual a diferença entre CDN e edge computing?'
    answer: 'Uma CDN aproxima conteúdo dos usuários; edge computing aproxima computação. Entrega versus decisões: a CDN responde a "sirva este arquivo rápido em qualquer lugar", funções de edge respondem a "rode esta lógica perto do usuário". Na prática os dois convergem — plataformas modernas de CDN executam código em seus pontos de presença — mas o modelo mental se sustenta.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'CDN — MDN Web Docs Glossary'
    url: 'https://developer.mozilla.org/en-US/docs/Glossary/CDN'
  - name: 'Content delivery network (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Content_delivery_network'
  - name: 'HTTP Cache-Control — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control'
  - name: 'Back4app file storage documentation'
    url: 'https://www.back4app.com/docs'
cta:
  title: 'Arquivos servidos rápido, desde o primeiro dia'
  text: 'Envie um arquivo ao Back4app e a URL que volta já é amigável a CDN por padrão — entrega pronta para cache de imagens, mídia e downloads, com banco de dados, autenticação e APIs já gerenciados ao lado. Nenhuma camada de distribuição para configurar.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-24'
translationKey: cdn-content-delivery-network
---

**Uma CDN é uma rede de servidores distribuídos que mantém conteúdo em cache perto dos usuários, para páginas e arquivos carregarem rápido em qualquer lugar.** O problema que ela resolve é física: uma requisição de São Paulo para um servidor em Frankfurt paga a viagem de ida e volta em latência, todas as vezes. Com uma CDN, a resposta sai de São Paulo — e um esclarecimento poupa confusão sem fim: ela *complementa* sua hospedagem, nunca a substitui.

## Principais pontos

| Pergunta | Resposta |
| --- | --- |
| O que é | Servidores de edge distribuídos guardando cópias em cache do seu conteúdo |
| Problema que resolve | Distância — a latência escala com a ida e volta até a sua origem |
| O mecanismo | Rotear ao edge mais próximo → cache hit responde na hora; miss busca na origem uma vez |
| Os controles | Headers Cache-Control, TTL, purge ou nomes de arquivo versionados |
| O que não é | Hospedagem web nem edge computing — entrega, não armazenamento ou lógica |

## Os controles que fazem tudo funcionar

O contrato inteiro de cache cabe em um único header HTTP — e é justamente a peça menos explicada de todo guia sobre CDN:

```text
# A instrução da origem para todo cache entre ela e o usuário:
Cache-Control: public, max-age=300, s-maxage=86400, stale-while-revalidate=3600

  public                  → qualquer cache pode armazenar isto
  max-age=300             → navegadores: fresco por 5 minutos
  s-maxage=86400          → edges da CDN: fresco por 24 horas
  stale-while-revalidate  → serve o stale na hora, atualiza em segundo plano

# A outra estratégia: nunca expirar, nunca purgar — versione o nome do arquivo
/_assets/app.3f9c1b.css   → cache "para sempre"; build novo significa URL nova
```

De onde os arquivos saem no seu app também importa — em um backend gerenciado, um upload retorna uma URL pronta para entrega, com o comportamento de cache já sensato de fábrica:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// Upload once; the returned URL serves from edge cache worldwide
const file = new Parse.File('hero.webp', { base64: imageData });
await file.save();
console.log(file.url()); // CDN-backed, cache-friendly URL
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final file = ParseFile(File('hero.webp'));
await file.save();
print(file.url); // CDN-backed, cache-friendly URL
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
let file = ParseFile(name: "hero.webp", data: imageData)
file.save { result in
  if case .success(let saved) = result {
    print(saved.url ?? "") // CDN-backed, cache-friendly URL
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val file = ParseFile("hero.webp", imageBytes)
file.saveInBackground { e ->
  if (e == null) Log.d("CDN", file.url) // CDN-backed, cache-friendly URL
}
```

## Anatomia de uma requisição

```mermaid
flowchart LR
  accTitle: Como uma CDN atende uma requisição
  accDescr: O usuário é roteado ao ponto de presença mais próximo; um cache hit é servido do edge imediatamente, enquanto um miss busca no servidor de origem, guarda a resposta em cache conforme o TTL dela e passa a servi-la localmente.
  U["Usuário"] --> R["Roteamento<br/>(PoP mais próximo)"]
  R --> E["Servidor de edge"]
  E -->|"cache hit"| U2["Resposta em ms"]
  E -->|"cache miss"| O["Servidor de origem"]
  O -->|"resposta + TTL"| E
```

O vocabulário de uma vez só: a **origem** é o seu servidor de verdade — a fonte da verdade. Um **PoP** (ponto de presença) é uma localização de data center da CDN; **servidores de edge** são as máquinas de cache dentro dele. O **cache-hit ratio** — a fração das requisições respondidas sem tocar a origem — é a métrica que o exercício inteiro otimiza, e as alavancas são os headers acima. O que melhora para o usuário é o **TTFB** (tempo até o primeiro byte) e, quando páginas completas são cacheadas no edge, as métricas de carregamento que decorrem dele.

## CDN vs. hospedagem web vs. edge computing

| Dimensão | Hospedagem web (origem) | CDN | Edge computing |
| --- | --- | --- | --- |
| Papel | Armazena o conteúdo autoritativo | Distribui cópias em cache | Executa lógica perto dos usuários |
| Responde a | "Onde meu site mora?" | "Por que ele é rápido em Tóquio?" | "Posso computar em Tóquio?" |
| Estado | Permanente | Temporário, limitado pelo TTL | Geralmente stateless |
| Sem isso | Sem site | Site lento, origem exposta | Ida e volta para cada decisão |
| Conteúdo típico | Tudo, uma vez | Assets estáticos, mídia, páginas inteiras em cache | Personalização, checagens de auth, rewrites |

A [definição da MDN](https://developer.mozilla.org/en-US/docs/Glossary/CDN) acrescenta a ressalva que as páginas de fornecedores pulam: scripts de CDN de terceiros são uma dependência de supply chain (atributos de integrity existem por um motivo), e um lookup extra de DNS até a CDN pode até custar tempo na primeira visita — alavanca, não mágica.

## Casos de uso comuns

- **Assets estáticos em escala.** CSS, JavaScript, fontes, imagens — nomes de arquivo fingerprinted mais TTLs longos transformam visitas repetidas em tráfego puro de edge.
- **Mídia e downloads.** Segmentos de vídeo e arquivos grandes, onde a banda da origem seria a conta e o gargalo.
- **Audiências globais.** A mesma página servida em menos de 100 ms em quatro continentes, sem operar servidores em quatro continentes.
- **Picos de tráfego e lançamentos.** O edge absorve a onda; a origem vê uma fração dela.
- **Postura de segurança.** Origem escondida atrás de um reverse proxy, TLS terminado no edge, ataques volumétricos dissipados pela rede.

## Você precisa de uma CDN? Matriz de decisão

| Uma CDN compensa quando… | Pule (ou adie) quando… |
| --- | --- |
| Usuários estão longe da sua origem | Sua audiência é local à região do seu servidor |
| Assets e mídia dominam seu tráfego | O app é pequeno, dinâmico e limitado pela API |
| Picos de tráfego fazem parte do negócio | O tráfego é baixo demais para manter o cache aquecido |
| A banda da origem é um custo real | A peça extra em movimento pesa mais que os ms economizados |
| Você quer absorção de DDoS na frente da origem | Você estaria cacheando respostas personalizadas (não dá) |

A linha honesta que ninguém imprime: em um site de pouco tráfego, as cópias em cache expiram entre um visitante e outro, toda requisição é um miss, e a CDN adiciona um salto por nada. Distância e volume são os insumos; sem nenhum dos dois, conserte outra coisa primeiro.

## Limitações e trade-offs

- **Conteúdo velho é o modo de falha padrão.** TTLs longos significam o arquivo de ontem servido com confiança hoje; a cura é o purge (lento, varia por CDN) ou nomes de arquivo versionados (melhor).
- **Invalidação de cache é genuinamente difícil.** É um dos dois famosos problemas difíceis por um motivo — projete as URLs para raramente precisar dela.
- **Conteúdo dinâmico resiste ao cache.** Respostas por usuário não podem ser compartilhadas; aceleração e lógica de edge ajudam, mas a origem continua fazendo o trabalho.
- **Uma dependência no caminho crítico.** Quedas de CDN são eventos de clima da internet; quando o edge cai, o "seu" site cai.
- **Depurar ganha uma camada.** Qual cache serviu isto? Com quais headers? Headers de cache-status e comportamento por edge passam a fazer parte da sua superfície de observabilidade.

## CDNs no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A história de CDN vem embutida na camada de arquivos: faça upload por qualquer SDK (as abas acima) e a URL retornada já está pronta para entrega — estável, cacheável e independente do tráfego dinâmico da sua API, o que mantém as metades cacheável e não cacheável do seu app separadas com limpeza. Frontends web hospedados no [Back4app Containers](https://www.back4app.com/container-as-a-service) assentam naturalmente atrás de qualquer CDN, com o padrão clássico — assets fingerprinted de vida longa, HTML de vida curta — configurado em um único header.