GH GambleHub

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.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.