Edge-cachés y POP
1) Qué es POP y por qué «borde»
POP (Point of Presence) es un nodo de red de entrega de contenido (CDN/edge) geográficamente cercano al usuario. Edge-caché es una capa de almacenamiento de respuestas directamente en POP que reduce:- Latencia (menor RTT al cliente).
- Carga y costo en origin (offload).
- Tráfico entre regiones/nubes (egress-ahorro).
Edge no es sólo un caché. Los POP modernos admiten enrutamiento L7, filtros WAF/bot, rate-limit, A/B/canareas, transformaciones y edge-compute (scripts/funciones).
2) Arquitecturas edge-caché
2. 1 Plano vs multinivel (tiered)
Plano: cada POP camina en origin. Simple, pero caro para el origin.
Tiered/Shield: POP → Shield POP (caché central) → origin. Shield acumula errores de caché, crea un «paraguas» para origin.
2. 2 Segmentos regionales
Divida los dominios de almacenamiento en caché por regiones/jurisdicciones (GDPR/localización de datos).
Opción: «EU-only POPs' y» Global POPs', claves/reglas separadas.
2. 3 Anycast + latency/geo-aware routing
Anycast lleva al cliente al POP más cercano por BGP.
Geo/latency-aware cambia entre RR/pools regionales por medidas RTT/errores activos.
3) Claves de caché, 'Vary', TTL y frescura
3. 1 Diseño de llaves
Normalizar las consultas: ordenar los parámetros de query, eliminar el ruido (utm, ref).
Incluye los ejes semánticos: 'tenant', 'locale', «versión del circuito» ('v = 3'), pero evita el PII.
Para el contenido privado - compartir el caché público y privado (ver § 7).
3. 2 Control de caché (HTTP)
Encabezados:- `Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60, stale-if-error=120`
- 'ETag '/' Last-Modified' para GET condicionales (304).
- Vary: minimiza la cardinalidad ('Accept-Encoding', 'Accept-Language', a veces 'Authorization '/' Cookie' para rutas privadas).
- Micro-cache para «casi-altavoz»: 1-5 segundos + SWR.
3. 3 Estrategias Stale
SWR (stale-while-revalidate): damos una respuesta obsoleta y actualizamos el fondo.
SIE (stale-if-error): si error origin usamos caché hasta 'SIE' -TTL.
Soft/Hard TTL: tiempo suave (stale), duro (error total).
4) Discapacidad: cómo actualizar «borde»
4. 1 Por clave y por etiqueta
PURGE/BAN por URL/prefijo - áspero pero rápido.
Surrogate-Key/Tags: asigne etiquetas a los objetos ('artículo: 42', 'categoría: 7'), baña la etiqueta - invalidez masiva sin exceso de URL.
4. 2 Discapacidad de eventos
Si los datos cambian en origin, publique eventos (Kafka/NATS) → edge-discapacitados llamen a BAN/PURGE/soft-expire.
4. 3 Versificación de artefactos
Para estática, content-hash en el nombre del archivo.
Para la API: cambie la versión de clave ('v = 4') cuando haya cambios incompatibles.
5) Protección de origen y rendimiento
5. 1 Origin shielding
Active Shield POP como el único punto de error → reduce la tormenta por origin en varias ocasiones.
5. 2 Coalescing/single-flight
En el borde, una solicitud «perfora» el caché cuando falta; los demás están esperando (no hay stampede que se ponga al día).
5. 3 Rate-limit/Queue/Shedding на edge
En caso de sobrecarga: restablezca las consultas de baja prioridad/anónimas en POP en lugar de en origen.
5. 4 Signed URL / Signed Cookie
El origen está oculto detrás del edge. Acceso al contenido privado - a través de enlaces/cookies firmados con TTL y atributos (IP/Geo/Path) para no distribuir «a todos».
6) Transporte y transformaciones
6. 1 HTTP/2–3 и QUIC
HTTP/2: multiplexación, heder compresión.
HTTP/3/QUIC: menos bloqueos HOL y mejor en canales perdidos → por debajo de p95/p99 TTFB.
6. 2 Compresión e imágenes
Brotli para texto, AVIF/WebP para imágenes, imagen-resizing en el borde (tamaño responsivo, DPR).
Opciones de caché por formato/tamaño: las claves incluyen 'width/format' (o'Vary: Accept'/Client-Hints).
6. 3 TLS/0-RTT (suavemente)
El reciclaje de sesiones acelera la instalación, 0-RTT puede ser vulnerable al replay → habilite sólo para GET idempotentes.
7) Público vs privado edge-caché
7. 1 Público
'Cache-Control: público, s-maxage =...' y el mínimo 'Vary'.
Adecuado para catálogo, noticias, imágenes, CDN estática.
7. 2 Privado/Personalizado
Opciones:- No almacenar en caché en el nivel de chared: 'Cache-Control: private' (caché del navegador).
- Key-segmentation: incluye tenant/user-id (o token hash) en la clave y marca como privado-compartido (cuidado con el almacenamiento y PII).
- Cookies firmadas y Edge-auth: el caché es público, pero el acceso es por firma (opciones con un estado de sesión encryptado en el borde).
8) Edge-compute (Workers/Functions)
Funciones fáciles en POP: reescritura de rutas/encabezados, división A/B, normalización de claves, lógica SWR, prefetch de recursos vecinos.
API local KV/Cache en POP para operaciones de milisegundos.
Limitaciones: tiempos cortos/memoria, ninguna conexiones de larga vida, trabajo atento con PII/regionalidad.
Ejemplo pseudo (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) Ejemplos de configuraciones
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-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 comportamiento CloudFront-style (esbozo)
Behavior A: '/images/' es un TTL largo, compresión, variado por formatos.
Behavior B: '/api/' - cortocircuito TTL, SWR, signed cookie, WAF/bot protection.
Origin Shield está habilitado, los estados 500/502/504 → 'stale-if-error'.
10) Observabilidad, SLO y presentación de informes
10. 1 Métricas
cache_hit_ratio (por POP/región/ruta), byte_hit_ratio.
origin_offload = 1 − (origin_requests / edge_requests).
TTFB/TTL por cuantiles, stale_responses_total, revalidations_total.
stampede_prevented_total, coalesced_waiters.
shield_hit_ratio (bajo tiered), origin_egress_bytes (costo).
10. 2 Registros/Tracks
Registros etiquetados con 'HIT/MISS/STALE/UPDATING/BYPASS', clave, TTL, POP, tenant.
En las pistas distribuidas, marca la fuente ('edge', 'origin') y la causa (revalidate/stale/error).
10. 3 ejemplos de SLO
«Для `/api/list`: p99 TTFB ≤ 250 мс, edge hit ≥ 70%, byte-hit ≥ 80%, origin error-offload ≥ 90%».
«La proporción de respuestas 'stale-if-error' ≤ 1% por día».
11) Seguridad, privacidad, cumplimiento
WAF/bot management - en edge para filtrar a origin.
Regionalidad de datos: almacenar artefactos privados sólo en POP válidos; utilice claves específicas de la región y ACL.
Firmas y tokens en edge, no dar respuestas privadas de caché público.
Minimización PII: no incluya datos personales en las claves; cifrar las cookies; TTL cortos para la personalización.
12) Recetas típicas
12. 1 «Casi dinámica» (cintas/listas)
Micro-cache 1-3 con + SWR en edge, shield incluido, single-flight, negative-cache para resultados vacíos de 1-5 s.
12. 2 Nubes de imágenes/medios
Edge Resise/Formating (WebP/AVIF), opciones de caché por 'width/format', TTL largo, discapacidad por etiquetas de contenido.
12. 3 API con personalización
'Cache-Control: privado' o cookie signada + clave-segmentación (tenant), TTL corta, SWR para partes «casi públicas» de la respuesta.
12. 4 Grandes ventas/picos
Calentamiento de recursos clave (prewarm), aumento de TTL por estática, agresivo SWR/SIE, límites estrictos en origin incluido por Shield.
13) Anti-patrones
Sin 'Vary' en diferentes respuestas → fugas/datos incorrectos.
Enorme 'Vary' → cardinalidad → bajo hit.
Caché compartido para prod/experiments → contaminación.
No hay un solo vuelo → una tormenta de errores en origin.
SWR sin restricciones → una carrera de actualización y una avalancha de solicitudes de validate.
Edge-caché de respuestas privadas como público → incidentes de seguridad.
Sin tiered/shield durante la carga de worldwide → sobrecalentamiento de origin.
14) Lista de verificación de implementación
- Mapee el recubrimiento POP, active anycast + latency-routing.
- Seleccione tiered/shield y las directivas single-flight/coalescing.
- Diseñe las llaves y Vary (cardinalidad mínima, sin PII).
- Configure TTL/SWR/SIE (soft/hard TTL) y negative-cache.
- Active la URL/cookie señalizada, oculte el origen, active los filtros WAF/bot.
- Organice la discapacidad: Surrogate-Key/BAN + event-driven.
- Levante las métricas hit/byte-hit/offload/TTFB y dashboards per-POP.
- Calentamiento antes de los picos, runbooks en tormenta/sobrecarga.
- Pruebas de privacidad/regionalidad, auditoría de claves y políticas.
- SLO/presupuesto erróneo para edge y criterios de auto-retoques TTL/SWR.
15) FAQ
P: ¿Cómo elegir TTL en el borde?
R: Aléjate de la obsolescencia admisible y del objetivo de hit-ratio. Para «casi-altavoz» - 1-5 con + SWR; para guías/imágenes: minutos/horas con discapacidad por evento/etiqueta.
P: ¿Cuándo necesita Shield POP?
R: Con tráfico global o llaves calientes: shield reduce drásticamente las faltas de origin y estabiliza las olas «que se ponen al día».
P: ¿Cómo puedo almacenar en caché las respuestas autorizadas?
R: Ya sea 'private' (navegador) o public con una cookie/URL signada y segmentación de clave (sin PII), o en general bypass para datos personales críticos.
P: ¿Qué hacer con el HTTP/3?
R: Incluir: el canal móvil/perdido es especialmente beneficioso. Controle la compatibilidad de proxy y fallback en el HTTP/2.
16) Resultados
Los cachés Edge y la red POP son la base de las plataformas de alta velocidad y bajo costo. El éxito está determinado por la clave correcta y 'Vary', la TTL/SWR/SIE razonable, la discapacidad por etiquetas/eventos, la protección de origen tiered/shield, así como la observabilidad (hit/offload/TTFB) y la disciplina de seguridad/privacidad. Siga la lista de verificación - y el «borde» se convertirá en su acelerador, no en una fuente de sorpresas.