Edge-caschi e POP

1) Cos'è POP e perché «bordo»

• Latenza (inferiore a RTT fino al client).
• Carico e costo per origin (offload).
• Traffico tra regioni/nuvole (risparmio egress).

Edge non è solo un caschetto. I POP avanzati supportano routing L7, filtri WAF/bot, rate-limit, A/B/canarini, trasformazioni e edge-compute (script/funzioni).

2) Architetture edge-cache

2. 1 Piatta vs su più livelli (tiered)

Piatto: ogni POP va su origin. Semplice, ma costoso per origin.
Tiered/Shield: POP → Shield POP (cache centrale) → origin. Shield accumula gli errori di kash, crea un'ombrello "per origin.

2. 2 Segmenti regionali

Separare i domini di cache per regione/giurisdizione (GDPR/Localizzazione dati).
Opzione «EU-only POPS» e «Global POPS», chiavi/regole separate.

2. 3 Anycast + latency/geo-aware routing

Anycast porta il client al POP più vicino per BGP.
Geo/latency-aware passa da RR/pool regionali alle misure attive RTT/errori.

3) Chiavi cache, «Vary», TTL e freschezza

3. 1 Design delle chiavi

Regolate le query: ordinate i parametri query, eliminate il rumore (utm, ref).
Attivare gli assi semantici: «tenant», «locale», «versione dello schema» («v = 3»), ma evitare il PII.
Per i contenuti privati - separare il cash pubblico e privato (vedere l'articolo 7).

3. 2 Controllo cache (HTTP)

• `Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60, stale-if-error=120`
• «ETAG »/« Last-Modified» per GET condizionati (304).
• Vary: minimizza la cardinalità (Accept-Encoding, Accept-Language, talvolta Authorization/Cookie per percorsi privati).
• Micro-cache per «quasi-altoparlanti»: 1-5 secondi + SWR.

3. 3 strategie stale

SWR (stale-while-revalidate) - Fornisce una risposta obsoleta e aggiorna lo sfondo.
SIE (stale-if-error) - Quando si verifica un errore origin, usiamo la cache pre-SIE -TTL.
Soft/Hard TTL: tempo morbido (stale), rigido (errore totale).

4) Disabilità: come aggiornare «bordo»

4. 1 Chiave e tag

PURGE/BAN per URL/prefisso - brutale, ma veloce.
Surrogate-Key/Tags - Assegnare tag agli oggetti («articolo: 42», «category: 7»), e segnare il tag - Disabilità di massa senza sovrapporsi URL.

4. 2 Eventi invalidità

Quando i dati vengono modificati in origin, pubblicare eventi (Kafka/NATS) i disabili edge chiamano BAN/PURGE/soft-expire.

4. 3 Versioning manufatti

Per lo statico - content-hash nel nome del file.
Per API - Cambia la versione della chiave ('v = 4') in caso di modifiche incompatibili.

5) Protezione degli origin e delle prestazioni

5. 1 Origin shielding

Accendere Shield POP come unico punto di errore riduce di più in più la tempesta sull'origin.

5. 2 Coalescing/single-flight

Sul bordo, una query «perfora» la cache quando fallisce; gli altri sono in attesa (nessuna stampede di raggiungimento).

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

In caso di sovraccarico: reimposta le richieste a bassa priorità/anonima in POP invece che in origin.

5. 4 Signed URL / Signed Cookie

Origin è nascosto dietro l'edge. Accesso ai contenuti privati tramite link/cookie firmati con TTL e attributi (IP/Geo/Path) per non distribuirli a tutti.

6) Trasporti e trasformazioni

6. 1 HTTP/2–3 и QUIC

HTTP/2: multiplex, heder compression.
HTTP/3/QUIC: meno blocchi HOL e meglio sui canali di → sotto p95/p99 TTFB.

6. 2 Compressione e immagini

Brotli per testo, immagine, immagine-resizing sul bordo (responsive sizes, DPR).
Opzioni Kash per formato/dimensione: le chiavi includono "width/format" (o'Vary: Accept "/Client-Hints).

6. 3 TLS/0-RTT (con attenzione)

Il riammodernamento delle sessioni accelera l'installazione, 0-RTT può essere vulnerabile al replay → includere solo per GET idropotenti.

7) Pubblico vs privato edge-cash

7. 1 Pubblico

Cache-Control: public, s-maxage =... e minimo «Vary».
Adatto per catalogo, news, immagini, CDN statico.

7. 2 Privato/Personalizzato

• Non memorizzare la cache a livello di Shaed: «Cache-Control: private» (cache del browser).
• Key-segmentation: abilita tenant/user-id (o token-hash) in chiave e contrassegna come private-shared (attenzione con storage e PII).
• Cookie Signed e Edge-auth: kash è pubblico, ma accesso tramite firma (opzioni con encrypted sessione state sul bordo).

8) Edge-compute (Workers/Functions)

Funzioni leggere su POP: riscrittura del percorso/intestazione, A/B split, regolazione delle chiavi, logica SWR, prefetch delle risorse adiacenti.
API locale KV/Cache su POP per operazioni in millisecondi.
Limitazioni: brevi timeout/memoria, mancanza di connessioni a lunga vita, lavoro attento con PII/regionalità.

Pseudo-esempio (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) Esempi di configurazione

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 Avvoy (filtro edge-cache)

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 comportamenti CloudFront-style (sketch)

Behavior A: '/immagini/' - TTL lungo, compressione, vary per formati.
Behavior B: '/api/' - TTL breve, SWR, cookie signed, WAF/bot.
Origin Shield è abilitato, stati'stale-if-errore '.

10) Osservazione, SLO e reporting

10. 1 Metriche

cache _ hit _ ratio (per POP/regione/route), byte _ hit _ ratio.
origin_offload = 1 − (origin_requests / edge_requests).
TTFB/TTL per quantiglia, stale _ responses _ total, revalidations _ total.
stampede_prevented_total, coalesced_waiters.
shield _ hit _ ratio (con tiered), origin _ egress _ bytas (costo).

10. 2 Logi/roulotte

Loghi con etichette «HIT/MISS/STALE/UPDATING/BYPASS», chiave, TTL, POP, tenant.
Nelle roulotte distribuite, segnare la fonte («edge», «origin») e la causa (revalidate/stale/errore).

10. 3 esempi SLO

«Для `/api/list`: p99 TTFB ≤ 250 мс, edge hit ≥ 70%, byte-hit ≥ 80%, origin error-offload ≥ 90%».
«La percentuale di risposte» stale-if-errore «è dell '1% in 24 ore».

11) Sicurezza, privacy, conformità

WAF/bot management - su edge per filtrare fino a origin.
Regionalità dei dati: conserva i manufatti privati solo in POP validi; utilizzare le chiavi regionali-specifiche e l'ACL.
Firme e token su edge, non dare risposte private da un cassetto pubblico.
Riduzioni PII: non includere i dati personali nelle chiavi cifrare i cookie; TTL brevi per la personalizzazione.

12) Ricette tipiche

12. 1 «Quasi altoparlante» (nastri/elenchi)

Micro-cache 1-3 con + SWR su edge, shield incluso, single-flight, negative-cache per risultati vuoti 1-5 s

12. 2 Nuvole di immagini/media

Edge-resease/formattazione (WebP/AVIF), cash-varianti per «width/format», TTL lunghi, disabili per tag di contenuto.

12. 3 API personalizzate

«Cache-Control: private» o cookie signed + chiave-segmentazione (tenant), TTL brevi, SWR per le parti «quasi pubbliche» della risposta.

12. 4 Grandi saldi/picchi

Riscaldamento delle risorse chiave (prewarm), aumento della TTL sulla statica, SWR/SIE aggressivo, limiti rigidi sull'origin attivato da Shield.

13) Anti-pattern

Senza «Vary», le differenze di risposta sono → o dati non validi.
L'enorme «Vary», la cardinalità, l'hit basso.
Cache condivisa per prod/experiments → l'inquinamento.
Nessun singolo-flight → una tempesta di errori su origin.
SWR senza restrizioni per le corse di aggiornamento e la valanga di query validate.
Edge-cash di risposte private come pubblico incidenti di sicurezza.
L'assenza di tiered/shield durante il carico di lavoro worldwide si surriscalda origin.

14) Assegno foglio di implementazione

• Mappare la copertura POP, attivare anycast + latency-routing.
• Selezionare tiered/shield e criteri single-flight/coalescing.
• Progettare le chiavi e Vary (cardinalità minima, senza PII).
• Configura TTL/SWR/SIE (soft/hard TTL) e negative-cache.
• Attivare l'URL/cookie, nascondere l'origin, attivare i filtri WAF/bot.
• Organizzare la disabilità: Surrogate-Key/BAN + event-driven.
• Sollevare le metriche hit/byte-hit/offload/TTFB e i dashboard per-POP.
• Riscaldamento prima dei picchi, runbooks per tempesta/sovraccarico.
• Test di privacy/regionalità, controllo delle chiavi e regole.
• Budget SLO/errato per edge e criteri per i tweet TTL/SWR.

15) FAQ

Q: Come selezionare TTL sul bordo?
A: Allontanati dall'obsolescenza accettabile e dall'obiettivo hit-ratio. Per «quasi-altoparlanti», 1-5 con + SWR; per le guide/immagini - minuti/ore con disabilità per eventi/tag.

Quando serve Shield POP?
A: Con il traffico globale o le chiavi calde, shield riduce drasticamente gli errori sull'origin e stabilizza le onde di raggiungimento.

Q: Come memorizzare la cache delle risposte autorizzate?
A: O «private» (browser), o public con cookie/URL e segmentazione della chiave (senza PII) o bypass per i dati personali critici.

Q: Cosa fare con HTTP/3?
A: Abilita: vince soprattutto il canale cellulare/perdita. Controlla la compatibilità tra proxy e fallback su HTTP/2.

16) Riepilogo

Edge-caschi e la rete POP sono le basi di piattaforme ad alta velocità e a basso costo. Il successo è determinato dalla chiave corretta e da «Vary», TTL/SWR/SIE ragionevoli, disabilità per tag/eventi, tiered/shield protezione origin, e osservabilità (hit/offload/TTFB) e disciplina della sicurezza/privacy. Seguite la lista degli assegni e il bordo sarà il vostro acceleratore, non la fonte di sorprese.