Edge-cajas e POP

1) O que é POP e porquê «borda»

• Latência (menor do que o RPT até o cliente).
• Carga e custo sobre origin (offload).
• Tráfego entre regiões/nuvens (economia egress).

Edge não é só kesh. O POP atual suporta roteamento L7, filtros WAF/bot, rate-limit, A/B/canários, transformações e edge-compute (acrobacias/funções).

2) Arquiteturas edge-cajado

2. 1 Plana vs de vários níveis (tiered)

Plano: cada POP vai ao origin. Simples, mas caro para origin.
Tiered/Shield: POP → Shield POP → origin. Shield acumula falhas de kesh, cria um «guarda-chuva» para origin.

2. 2 Segmentos regionais

Divida os domínios de armazenamento por região/jurisdição (GDPR/Localização de Dados).
A opção é «EU-only POPs' e» Global POPs', chaves/regras separadas.

2. 3 Anycast + latency/geo-aware routing

Anycast leva o cliente para o POP mais próximo por BGP.
Geo/latency-aware alterna o RR/pool regional por medidas ativas de RR/erro.

3) Chaves de dinheiro, 'Vary', TTL e frescor

3. 1 Design de chaves

Normalize as pesquisas: classifique os parâmetros query e remova o ruído (utm, ref).
Inclua os eixos semânticos «tenant», «local», «versão do esquema» («v = 3»), mas evite o PII.
Para os conteúdos privados - Separar o kesh público e privado (consulte parágrafo 7).

3. 2 Controle de armazenamento em dinheiro (HTTP)

• `Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60, stale-if-error=120`
• 'ETAG '/' Last-Modificed' para GET condicional (304).
• Vary: Minimize a cardinalidade ('Accept-Encoding', 'Accept-Language', 'Autorization '/' Cookie' para caminhos privados).
• Micro-caixa para «quase-dinâmica»: 1-5 segundos + SWR.

3. 3 estratégias Stale

SWR (stale-while-revalidate): Damos uma resposta obsoleta e atualizamos o fundo.
SIE (stale-if-erro): Quando o origin estiver errado, usaremos kesh antes de 'SIE' -TTL.
Soft/Hard TTL: prazo suave (pode ser stale), dura (falha total).

4) Deficiência: como atualizar «borda»

4. 1 Por chave e por marcas

PURGE/BAN por URL/prefixo - grosseiro, mas rápido.
Surrogate-Key/Tags: Dê marcas de formatação («artigo: 42», «category: 7»), banhe-se pela marca - deficiente em massa sem excesso de URL.

4. 2 Deficiência de evento

Quando você alterar os dados no origin, publique eventos (Kafka/NATS) → os deficientes edge chamam BAN/PURGE/soft-expire.

4. 3 Versionização de artefatos

Para status, o conteúdo-hash está no nome do arquivo.
Para API - Altere a versão da chave ('v = 4') para alterações incompatíveis.

5) Proteção de origin e desempenho

5. 1 Origin shielding

Inclua o Shield POP como o único ponto de falhas → reduz repetidamente a tempestade pelo origin.

5. 2 Coalescing/single-flight

Na borda, um pedido «perfura» o kesh ao falhar; os outros estão à espera (não há estampede de alcançamento).

5. 3 Rate-limit/Queue/Shedding на edge

Quando você estiver sobrecarregado, reinicie as solicitações de baixa prioridade/anônima para o POP, e não para o origin.

5. 4 Signed URL / Signed Cookie

O Origin está escondido atrás do edge. Acesso a conteúdo privado por meio de links/cookies assinados com TTL e atributos (IP/Geo/Path) para não distribuir «a todos».

6) Transporte e transformação

6. 1 HTTP/2–3 и QUIC

HTTP/2: multiplexação, compressão de heder.
HTTP/3/QUIC: menos bloqueios HOL e melhor em canais de perda → abaixo de p95/p99 TTFB.

6. 2 Compressão e imagens

Brotli para texto AVIF/WebP para imagens, image-resizing na borda (responsive sizes, DPR).
Opções Kesh em formato/tamanho: as chaves incluem 'width/formato' (ou 'Vary: Accept'/Clientes-Hants).

6. 3 TLS/0-PTT (cuidado)

As sessões de ressampling aceleram a instalação, 0-PTT pode ser vulnerável a replay → inclua apenas para GET Idempotante.

7) Público vs privado edge-kesh

7. 1 Público

'Cachê-Controle: público, s-maxage =...' e 'Vary' mínimo.
Adequado para catálogo, notícias, imagens, CDN estático.

7. 2 Privado/Personalizado

• Não deixar o nível de armazenamento de «Cachê-Controle: private» (kesh do navegador).
• Key-segmentation: inclua tenant/user-id (ou token-hash) na chave e marca como private-shared (cuidado com armazenamento e PII).
• Cookies e Edge-auth: kesh é público, mas acesso por assinatura (opções com encrypted sessions state na borda).

8) Edge-compute (Workers/Functions)

Funções fáceis no POP: reescrever caminhos/cabeçalhos, A/B split, normalizar chaves, lógica SWR, prefetch de recursos vizinhos.
API local KV/Cachê no POP para operações milissegundas.
Limitações: tempo curto/memória, falta de conexões de longa vida, trabalho atento com PII/regionalidade.

Pseudo-exemplo (Workers-like)

js export default {
async fetch(req, env) {
const key = normalize(req);
let res = await caches. default. match(key);
if (res) return withHitHeader(res, "HIT");

res = await fetch(req, { cf: { cacheEverything: true }});
const ttl = computeTTL(res);
eventWaitUntil(caches. default. put(key, res. clone(), { expirationTtl: ttl }));
return withHitHeader(res, "MISS");
}
}

9) Exemplos de configuração

9. 1 Nginx: micro-cache + SWR

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:200m inactive=30m;
map $request_method $skip_cache { default 0; POST 1; PUT 1; DELETE 1; }

server {
location /api/list {
proxy_cache api;
proxy_cache_key "$scheme://$host$uri$is_args$args";
proxy_cache_valid 200 2s;          # micro-cache proxy_cache_use_stale error timeout updating;# SIE + SWR proxy_cache_background_update on;
add_header X-Edge-Cache $upstream_cache_status;
proxy_pass http://origin_pool;
}
}

9. 2 Varnish: surrogate keys и BAN

vcl sub vcl_recv {
if (req. method == "BAN") {
if (req. http. Surrogate-Key) {
ban("obj. http. Surrogate-Key ~ " + req. http. Surrogate-Key);
return (synth(200, "Banned"));
}
}
}

sub vcl_deliver {
set resp. http. Surrogate-Key = "article:42 tag:author:7";
set resp. http. Cache-Control = "public, s-maxage=300, stale-while-revalidate=60";
}

9. 3 Envoy (filtro edge-cachê)

yaml http_filters:
- name: envoy. filters. http. cache typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. cache. v3. CacheConfig typed_config:
"@type": type. googleapis. com/envoy. extensions. http. cache. simple_http_cache. v3. SimpleHttpCacheConfig

9. 4 CloudFront-style comportamento (esboço)

Behavior A: '/images/' - TTL longo, compressão, vary em formatos.
Behavior B: '/api/' - TTL curto, SWR, cookie sinalizado, WAF/bot-proteção.
O Origin Shield está incluído, os estados 'stale-if-erro'.

10) Observabilidade, SLO e relatórios

10. 1 Métricas

cache _ hit _ ratio (por POP/região/rota), byte _ hit _ ratio.
origin_offload = 1 − (origin_requests / edge_requests).
TTFB/TTL por quanteis, stale _ responses _ total, revalidações _ total.
stampede_prevented_total, coalesced_waiters.
shield _ hit _ ratio (para tiered), origin _ egress _ bytes (valor).

10. 2 Logs/trens

Logs com marcas de 'HIT/Miss/STALE/UPDATING/BYPASS', chave, TTL, POP, tenant.
Nos trailers distribuídos, assinale a origem ('edge', 'origin') e a causa (revalidate/stale/erro).

10. 3 exemplos SLO

«Для `/api/list`: p99 TTFB ≤ 250 мс, edge hit ≥ 70%, byte-hit ≥ 80%, origin error-offload ≥ 90%».
«A proporção de respostas 'stale-if-erro' ≤ 1% em 24 horas».

11) Segurança, privacidade, conformidade

WAF/bot management - em edge para filtragem até origin.
Regionalidade dos dados: armazene os artefatos privados apenas em POP aceitáveis; use chaves regionais e específicas e LCA.
Assinaturas e tokens em edge, não dê respostas privadas a partir de um cachê público.
PII Minimização: Não inclua dados pessoais nas chaves; criptografe os cookies; TTL curtos para personalização.

12) Receitas típicas

12. 1 «Quase dinâmica» (fitas/listas)

Micro-cachê 1-3 com + SWR em edge, shield incluído, single-flight, negativo-cachê para resultados vazios de 1-5 s.

12. 2 Nuvens de imagens/mídia

Edge-ressaiz/formatação (WebP/AVIF), opções em dinheiro por 'width/formato', TTL longo, deficiência por marcas de conteúdo.

12. 3 API com personalização

'Cachê-Controle: private' ou cookie assinalado + segmentação de chave (tenant), TTL curto, SWR para as partes «quase públicas» da resposta.

12. 4 Grandes vendas/picos

Aquecimento de recursos-chave (prewarm), aumento de TTL para estática, SWR/SIE agressivo, limites rígidos para origin incluído pelo Shield.

13) Anti-pattern

Sem 'Vary', as respostas diferentes → vazamentos/dados errados.
Enorme 'Vary' → cardenalidade → hit baixo.
Dinheiro compartilhado para prod/experiments → poluição.
Sem single-flight → uma tempestade de falhas no origin.
SWR sem restrições → corrida de atualização e avalanche de solicitações de validate.
Edge-kesh respostas privadas como público → incidentes de segurança.
Falta de tiered/shield na carga worldwide → superaquecimento origin.

14) Folha de cheque de implementação

• Mapeie o revestimento POP, ative o anycast + latency-routing.
• Selecione tiered/shield e as políticas single-flight/coalescing.
• Projete as chaves e Vary (cardinalidade mínima, sem PII).
• Configure o TTL/SWR/SIE (soft/hard TTL) e o negativo-cachê.
• Inclua o signed URL/cookie, esconda o origin e inclua os filtros WAF/bot.
• Organize a deficiência: Surrogate-Key/BAN + event-driven.
• Levante as métricas hit/byte-hit/offload/TTFB e dashboard per-POP.
• Aquecido antes dos picos, runbooks para tempestade/sobrecarga.
• Testes de privacidade/regionalidade, auditoria de chaves e políticas.
• SLO/orçamento errado para edge e critérios de TTL/SWR automático.

15) FAQ

Q: Como escolher um TTL na borda?
A: Afaste-se da obsolescência aceitável e do objetivo hit-ratio. Para «quase-dinâmicas» - 1-5 com + SWR; para guias/imagens - minutos/horas com deficiência por evento/formatação.

Quando é que o Shield POP precisa?
A: Com tráfego global ou chaves quentes, o shield reduz drasticamente as falhas de origin e estabiliza as ondas de suprimento.

Q: Como encaixar as respostas autorizadas?
A: Ou 'private' (navegador) ou público com cookie/URL e segmentação de chave (sem PII) ou em geral bypass para dados pessoais críticos.

Q: O que fazer com HTTP/3?
A: Incluir: ganha especialmente o canal de celular/perda. Controle a compatibilidade entre proxy e fallback no HTTP/2.

16) Resultados

Edge-keshi e rede POP são as bases de plataformas de alta velocidade e de baixo custo. O sucesso é determinado pela chave correta e 'Vary', TTL/SWR/SIE razoável, deficiência por marcas/eventos, tiered/shield proteção origin, observabilidade (hit/offload/TTFB) e disciplina de segurança/privacidade. Siga a folha de cheques e «borda» será o seu acelerador, não a fonte de surpresas.