La latencia que no medimos

Una de las primeras métricas que pedimos a un cliente nuevo es el RTT promedio desde sus usuarios hasta su backend. La respuesta más común: “no estoy seguro, pero el sitio se ve rápido cuando entro desde la oficina.”

La oficina, por supuesto, suele estar a la vuelta del data center. Tus usuarios reales no.

Hicimos una medición en una aplicación financiera del cliente con servidores en us-east-1 (Virginia) y usuarios mayoritariamente en República Dominicana, El Salvador y Guatemala. RTT promedio:

Cada interacción que requiere ida y vuelta — autenticación, validación, lookup — paga ese costo. Una pantalla que hace 6 requests secuenciales gasta medio segundo solo en latencia.

Edge no es CDN

Hay confusión común. Un CDN cachea respuestas estáticas cerca del usuario. Edge computing ejecuta lógica cerca del usuario. La diferencia operativa:

• CDN: tu HTML, CSS, imágenes viven en el edge. Tu lógica vive en el origen.
• Edge: tu HTML y la función que decide qué HTML servir viven en el edge.

Para sitios mayoritariamente de lectura, un CDN puede ser suficiente. Para aplicaciones interactivas — autenticación, sesiones, validación, personalización — el edge es donde gana.

Cuándo sí

El edge brilla cuando:

1. Tu lógica tiene poco estado. Funciones que validan, transforman o enrutan sin mantener sesión pesada.
2. El acceso a datos puede ser eventual. Tienes una réplica de lectura cerca o un cache que te sirve la mayoría del tráfico.
3. El usuario está lejos de tu origen. Esta es la condición del Caribe y Centroamérica para casi cualquier despliegue en US/EU.
4. Quieres servir a múltiples regiones sin replicar infra. Una sola función desplegada al edge sirve 300+ ciudades automáticamente.

Casos reales donde lo aplicamos:

• ECF SSD API: cada llamada de e-CF va al edge más cercano al cliente, valida el XML, firma localmente (sin tocar la clave privada del cliente — eso lo hace el SDK), y solo viaja a DGII desde el edge más cercano al endpoint oficial. Promedio end-to-end: <2s incluyendo ACECF.
• Geolocalización de contenido: un usuario en CR ve el contenido localizado sin esperar a que un origen decida qué servirle.
• A/B testing sin flash: la decisión del bucket se toma en el edge, no en el cliente — el usuario no ve un flash de la variante incorrecta.

Cuándo no

El edge es la respuesta equivocada cuando:

1. Tu lógica necesita transacciones largas. Edge no es bueno para coordinar 12 escrituras atómicas. Para eso, el origen.
2. Tu sesión es grande y cambia mucho. Si necesitas reconstruir 50 KB de estado por request, el edge te va a costar más que ganar.
3. Tus datos solo viven en un lugar. Si toda tu base está en us-east-1 y cada request del edge tiene que ir a buscarla, regresa la latencia que querías evitar.
4. Cumplimiento exige geolocalización estricta. Algunos reguladores demandan que los datos no salgan de un país. El edge complica esto si no eliges bien tu proveedor.

Patrones que funcionan

1. Edge como “front door”

Toda request entra por el edge. La autenticación, rate limiting, A/B testing, redirects ocurren ahí. Solo las operaciones que necesitan el estado completo tocan el origen.

// Edge Worker (corre en 300+ ciudades)
export default {
  async fetch(request, env) {
    const session = await validateJWT(request, env.JWT_SECRET)
    if (!session) return new Response('Unauthorized', { status: 401 })

    // 80% de las requests se resuelven aquí
    if (request.url.includes('/api/profile')) {
      const cached = await env.CACHE.get(`profile:${session.userId}`)
      if (cached) return new Response(cached)
    }

    // El resto va al origen
    return fetch(env.ORIGIN_URL, request)
  }
}

2. Cache con purge inteligente

KV o D1 de Cloudflare como cache regional. La invalidación específica vence al TTL global.

// Cuando el perfil cambia en el origen, purgamos desde ahí
await fetch('https://api.cloudflare.com/.../purge', {
  method: 'POST',
  body: JSON.stringify({ keys: [`profile:${userId}`] })
})

3. Edge para validación, origen para escrituras

Validar el payload de un POST en el edge ahorra round-trips al origen para requests inválidos. El origen solo ve lo que ya pasó las primeras barreras.

Lo que pagas por mover al edge

Honestidad técnica:

• Cold starts: en el edge son menos severos que en Lambda, pero existen. Para latencia <50ms, despliega tu worker en formato compilado, no como bundle dinámico.
• Debugging: tu stack trace ya no está en un servidor que controlas. Necesitas observabilidad estructurada desde el día uno.
• Límites de runtime: CPU time, memoria, número de subrequests. Tu lógica de “edge” no puede ser lo mismo que un servidor.
• Estado: el edge es por diseño stateless. Si tu app depende de mantener estado en RAM, vas a sufrir.

Cómo medir si esto te conviene

Una métrica simple antes de empezar: time to first byte (TTFB) por región.

curl -w "%{time_starttransfer}\n" -o /dev/null -s https://tu-app.com/api/health

Hazlo desde un VPS en cada país donde tienes usuarios serios. Compara con lo que mediste en tu oficina. Si la diferencia es >100ms y tu app hace múltiples requests por interacción, el edge te paga solo.

Si solo es 20-30ms de diferencia y tu volumen es bajo, probablemente el edge no es tu mayor palanca. Optimiza el origen primero.

Cierre

Edge no es la respuesta a todo. Pero para una región como la nuestra — donde el usuario promedio está geográficamente lejos de los data centers principales — es una herramienta que cambia conversaciones. La diferencia entre “el sistema se siente lento” y “el sistema vuela” muchas veces es la decisión de mover la lógica antes que esperar al cable.

— Equipo SSD