El presupuesto de latencia de una redirección de URL tiene dos regímenes. Por debajo de ~50ms en p50, estás en territorio de edge POP: anycast enruta al usuario a una caché cercana y la redirección responde antes de que el handshake TCP resulte costoso. Por encima de ~50ms, estás en territorio de DNS puro: el balanceo de carga basado en DNS enruta al cliente en el momento de la resolución de nombres, la redirección implica un round-trip TCP transcontinental y el presupuesto incluye ese round-trip. Las arquitecturas se parecen superficialmente (ambas sirven un 302). Los perfiles de rendimiento no son los mismos. Este artículo es la comparativa.
Para una lectura en profundidad sobre el presupuesto de latencia, alcanzar p95 < 15ms en redirecciones es el artículo de referencia. Este post trata la decisión arquitectónica que hay detrás.
Qué significa realmente "enrutamiento solo con DNS"
El enrutamiento solo con DNS responde a la pregunta "¿a qué origen debe conectarse este cliente?" con la resolución DNS, no con la ruta TCP. Un usuario en Sídney resuelve r.ejemplo.com y el proveedor DNS (enrutamiento por latencia de Route 53, GeoDNS en Cloudflare, NS1, etc.) devuelve la IP del origen más cercano, por ejemplo, la instancia de Sídney de tu servicio de redirección.
La arquitectura:
Cliente (Sídney) ──consulta DNS── DNS autoritativo
│ │
│ devuelve IP del pod de Sídney│
↓
Origen Sídney ──redirección 302──→ Cliente
El proveedor DNS no ve la solicitud HTTP real. Solo ve la consulta del resolver, y ese resolver podría estar en un país vecino, con lo que "más cercano" se convierte en una suposición. La solicitud HTTP en sí es un round-trip al origen elegido.
Coste del round-trip. La ruta más rápida es un handshake TCP más un intercambio HTTP al origen más cercano. Si el origen más cercano está a 40ms (Sídney -> Sídney local), la redirección se resuelve en ~60-80ms de tiempo real (handshake + solicitud + respuesta).
Modo de fallo. Cuando el origen elegido cae, los TTLs de DNS se convierten en el cuello de botella. Un TTL de 60 segundos significa que los clientes pueden tardar hasta un minuto en detectar el fallo y reintentar contra una IP diferente. La cadencia de las comprobaciones de salud del proveedor DNS establece la ventana de recuperación real.
Qué significa realmente "enrutamiento con edge POP"
El enrutamiento con edge POP despliega una flota de servidores de caché en muchas regiones, todos respondiendo desde la misma IP anycast. El primer paquete del cliente a esa IP es enrutado por BGP al POP topológicamente más cercano, no el más cercano en distancia geográfica, sino el más cercano en términos de red (menos saltos de router, menor latencia medida).
La arquitectura:
Cliente (Sídney) ──paquete a IP anycast── POP más cercano por BGP (Singapur)
│
¿Acierto de caché? responde 302
│
Fallo de caché -> origen (Frankfurt)
Caché -> responde 302
El POP más cercano por BGP sirve la redirección desde caché. Los aciertos de caché omiten el origen por completo. Los fallos de caché son poco frecuentes (el primer fallo de un enlace popular tras un despliegue; el despliegue invalida una fila por slug, no toda la caché).
Coste del round-trip. Un acierto de caché responde en 5-15ms de tiempo real (handshake TCP al POP local, respuesta inmediata). Un fallo de caché añade un round-trip transcontinental de ~80-150ms al origen, pero ese round-trip ocurre una sola vez y luego la fila queda en caché en el POP para la siguiente solicitud.
Modo de fallo. Cuando un POP falla, BGP retira el prefijo. El siguiente paquete del cliente va automáticamente al POP más cercano siguiente. La recuperación es subsegundo, no subminuto.
Las cuatro métricas que determinan qué arquitectura encaja
-
Número de orígenes. Si tienes un solo origen (despliegue en una única región), el enrutamiento DNS no puede ayudar: no hay nada entre lo que enrutar. Los POPs anycast añaden valor al poner cachés delante del único origen.
-
Tasa de aciertos de caché. Los edge POPs solo son rápidos cuando la caché responde. Los acortadores de URL tienen tasas de aciertos del 95%+: el mapa slug-destino es pequeño y dominado por lecturas. Si la tasa de aciertos de tu carga de trabajo es inferior al 50%, los edge POPs se degradan a "un salto extra antes del origen" y el enrutamiento DNS es la arquitectura más limpia.
-
Dispersión geográfica de tus usuarios. Si el 90%+ de tus usuarios están en un solo país, ambas arquitecturas rinden de forma similar: un origen en ese país ya está a <30ms de todos. Si tus usuarios están repartidos en varios continentes, la arquitectura de edge POP empieza a ganar. Un usuario en Sídney conectándose a un origen solo en Frankfurt mediante enrutamiento DNS paga el RTT transcontinental (~180-220ms de handshake TCP) en cada redirección. Con un edge POP en Singapur, ese mismo usuario paga ~25ms.
-
Tolerancia a la lenta propagación en caso de fallo. La recuperación basada en DNS está limitada por el almacenamiento en caché del TTL del resolver más lento. Algunos resolvers no respetan los TTLs bajos; limitan el TTL mínimo a 60 o 300 segundos. Si tu acortador de URL necesita a veces desconectar un origen (despliegue, mantenimiento, caída de región), el enrutamiento DNS deja una larga cola de clientes en el origen caído. Anycast retira el prefijo en subsegundo.
Aplica las cuatro métricas a una carga de trabajo típica de un acortador de URL:
- Número de orígenes: normalmente 2-3 (multirregión para redundancia)
- Tasa de aciertos de caché: 95-99% (el mapa de slugs es pequeño)
- Dispersión geográfica: normalmente multicontinente (cualquier marca de cara al consumidor)
- Tolerancia a fallos: cero (el enlace está en materiales impresos; el tiempo de inactividad cuesta confianza)
Las cuatro apuntan hacia edge POPs. La arquitectura solo con DNS es más apropiada para herramientas internas de SaaS B2B donde la superficie de redirección es regional y el mapa de slugs cambia con frecuencia (más invalidaciones de caché que lecturas).
Cómo se ven realmente las cifras de latencia
Realizamos pruebas comparativas de ambas arquitecturas desde cuatro ubicaciones con la misma carga de trabajo (un solo enlace corto, primero con caché fría y luego cálida). Las cifras a continuación son p50/p95 de 1000 solicitudes secuenciales por ubicación.
Enrutamiento solo con DNS (origen único en Frankfurt, enrutamiento GeoDNS):
| Ubicación del origen | Cliente -> Frankfurt | p50 | p95 |
|---|---|---|---|
| Frankfurt | <1ms | 4ms | 9ms |
| Londres | 14ms | 22ms | 35ms |
| Nueva York | 90ms | 110ms | 145ms |
| Singapur | 165ms | 195ms | 240ms |
Enrutamiento con edge POP (anycast en FRA, ASH, SGP), acierto de caché:
| Ubicación del cliente | Enruta a POP | p50 | p95 |
|---|---|---|---|
| Frankfurt | FRA | 3ms | 7ms |
| Londres | FRA | 11ms | 18ms |
| Nueva York | ASH | 5ms | 9ms |
| Singapur | SGP | 4ms | 8ms |
La diferencia es más notable en las ubicaciones de la cola larga. Frankfurt tiene cifras similares en ambas porque es el origen en el caso de DNS puro. Singapur es el caso más dramático: de 195ms a 4ms en p50, porque la arquitectura con edge POP responde directamente desde Singapur. La arquitectura solo con DNS paga el round-trip transcontinental en cada redirección, sin importar lo bien cacheado que esté.
Equilibrio de costes
Los edge POPs cuestan más por redirección con bajo volumen. El coste fijo de ejecutar un POP (incluso uno pequeño en un servidor Hetzner Falkenstein) es real. Con menos de 100.000 redirecciones/mes, el enrutamiento DNS puro contra un único origen es más barato.
El punto de cruce está alrededor de 1 millón de redirecciones/mes. Por encima de esa cifra, la arquitectura de edge POP gana en coste por redirección porque las respuestas de aciertos de caché no tocan el cómputo ni el ancho de banda del origen. El origen escala para las recargas de caché (~1% de las solicitudes) en lugar de para el volumen completo de solicitudes.
La mayoría de los acortadores de URL están por encima del punto de cruce desde el primer día porque la distribución de la carga de trabajo tiene colas pesadas: unos pocos enlaces muy calientes acaparan la mayor parte del volumen de clics, y esos enlaces tienen tasas de aciertos de caché prácticamente infinitas.
Lo que los edge POPs no resuelven
Los edge POPs no son una mejora universal. Hay tres cargas de trabajo para las que las hacen más lentas, no más rápidas:
-
Escrituras. Crear un nuevo enlace, actualizar un destino: estas operaciones tienen que llegar al origen autoritativo y luego propagarse a la capa de invalidación de caché. La latencia de lectura es excelente; la latencia de escritura es aproximadamente la misma que la ruta solo al origen.
-
Redirecciones personalizadas. Los smart links que enrutan según la identidad del usuario (no solo por slug) no pueden almacenarse en caché en el POP: necesitan llegar al origen cada vez para leer el perfil del usuario. El POP se convierte en un proxy delgado de terminación TLS que añade 5-10ms a lo que de otro modo sería una conexión directa al origen. Para la mayoría de los acortadores de URL esto está bien porque las redirecciones personalizadas son una minoría pequeña del tráfico. Para los productos de deep-link (Branch, Adjust), la tasa de personalización se acerca al 50%, lo que cambia el cálculo arquitectónico.
-
Destinos restringidos por geografía. Si el destino de la redirección cambia según la geografía del usuario (página de destino diferente por país), la clave de caché debe incluir el país. Eso fragmenta la caché: en lugar de una fila por slug, tienes N filas por slug para N países admitidos. La tasa de aciertos de caché cae; el coste de memoria de la caché sube. Los POPs siguen ayudando, pero menos.
Para los acortadores de URL, el tercer caso es el que hay que vigilar. La mayoría de los enlaces cortos se resuelven en una sola URL independientemente de la geografía del usuario, por lo que una clave de caché única funciona. Pero en cuanto añades variantes por país, la ecuación de coste cambia.
Cómo lo hace Elido
Tres POPs (Hetzner Falkenstein, Hetzner Ashburn, OVH Singapur), anycast sobre un /24 propio. Caddy en el edge para TLS y certificados bajo demanda; fasthttp detrás de Caddy para la redirección en sí. Caché de dos niveles: LRU en proceso (L1, ~10.000 slugs más calientes en memoria) -> Cluster Redis (L2, conjunto completo de slugs). Un fallo de caché cae al endpoint gRPC de api-core, que lee desde Postgres.
Cadencia de recarga de caché: cualquier actualización al destino de un enlace publica un evento de invalidación en Redpanda. Los edge POPs se suscriben y eliminan su entrada L1 para el slug afectado. La siguiente solicitud a ese slug acierta en L2 (todavía caliente) y rellena L1. La latencia de invalidación en p95 es ~120ms en los tres POPs.
Esta arquitectura se explica con detalle operativo en el artículo de referencia sobre redirecciones con p95 < 15ms. El documento de arquitectura en /docs/architecture/edge-redirect tiene el diagrama completo.
El árbol de decisión
Una lista de verificación breve si estás eligiendo entre arquitecturas DNS puro y edge POP:
- Base de usuarios en un solo país + un solo origen? DNS puro está bien. No sobre-ingenierices.
- Usuarios en varios países + tasa de aciertos de caché alta? Edge POPs. La mejora de latencia es dramática en las ubicaciones de la cola larga.
- Usuarios en varios países + redirecciones personalizadas en más del 50% del tráfico? Mixto. Los POPs ayudan con la terminación TLS pero no con la redirección en sí. Considera enrutamiento DNS más una pequeña flota de POPs solo para terminación SSL.
- SLA estricto en velocidad de conmutación por error? Los edge POPs ganan: la retirada de BGP supera el almacenamiento en caché de TTLs DNS por órdenes de magnitud.
- Menos de 1 millón de redirecciones/mes? DNS puro es más barato. Reevalúa al superar 1 millón.
No existe una respuesta que sirva para todos. Los acortadores de URL específicamente tienden a encajar en el perfil "usuarios en varios países + tasa de aciertos de caché alta + SLA estricto en conmutación por error", que es la razón por la que la mayoría de los acortadores de URL en producción terminan migrando a una arquitectura con edge POP. El coste de la transición (re-arquitecturar la recarga de caché, elegir proveedores de POP, configurar BGP) es real pero acotado.
Relacionado en el blog
- Alcanzar p95 < 15ms en redirecciones desde Frankfurt, Ashburn y Singapur - referencia, con el detalle operativo
- Estrategia de caché para redirecciones de URL: qué desalojar y cuándo - la arquitectura de caché L1/L2
- Ingesta de clics fire-and-forget - qué ocurre en la ruta de redirección que no es la consulta a la caché
- Por qué ClickHouse para análisis de clics (y no Postgres) - el lado de análisis de la misma arquitectura
- Short links como Terraform: la referencia de ingeniería - IaC para gestionar la configuración del edge
Prueba Elido
Pega una URL, obtén un enlace corto
Sin registro. El enlace vive 30 días. Crea una cuenta para conservarlo.
Gratis, sin registro · 2 por día