miji.beLa computación en el borde es una técnica que procesa las solicitudes en ubicaciones de borde geográficamente cercanas al usuario, y plataformas como Cloudflare Workers, AWS CloudFront Functions, AWS Lambda@Edge y Fastly Compute son ejemplos representativos. La redirección de una URL corta se completa en un solo paso, por lo que es un proceso adecuado para ejecutarse en el borde.
La ejecución en el borde tiene tres ventajas. La primera es la latencia: como se procesa en puntos cercanos al usuario, como Tokio, Osaka, Singapur o Fráncfort, el tiempo hasta la respuesta se acorta. La segunda es el coste: según la tarifa por uso de AWS a agosto de 2026, Lambda@Edge cuesta $0,60 por 1 millón de solicitudes y CloudFront Functions, $0,10 por 1 millón de invocaciones. Cloudflare Workers incluye una cantidad determinada de solicitudes en la cuota básica mensual y cobra el exceso según el número de solicitudes y el tiempo de CPU. En todos los casos, es un nivel que suele resultar más barato que mantener nodos de cómputo permanentes. La tercera es la disponibilidad: la ejecución en el borde se ve poco afectada por las caídas de una sola región, y aunque caigan algunos puntos, los demás pueden seguir respondiendo.
La contrapartida con la consistencia es el principal punto de debate de la ejecución en el borde. Los datos de destino de las redirecciones de URLs cortas se guardan en Cloudflare Workers KV, que se puede leer en los puntos del borde, o en DynamoDB Global Tables, que se replica en varias regiones, entre otros. Sin embargo, hay un desfase de tiempo hasta que una escritura se hace visible en otros puntos o regiones (documentación de cada empresa a octubre de 2026). Puede ocurrir que, justo después de emitir una nueva URL corta, no haya coincidencia en un borde concreto del mundo. Las opciones de arquitectura se dividen según se pueda tolerar esto o no.
Cuando se necesita consistencia fuerte, existe una configuración que hace una primera comprobación en la caché del borde y, en caso de fallo, consulta al origen (la base de datos central). Por ejemplo, en AWS el flujo consiste en intentar el cotejo del código corto en el lado del borde, consultar DynamoDB Global Tables desde Lambda@Edge si no se encuentra y guardar esa respuesta en la caché de CloudFront. Justo después de una nueva emisión hay un pequeño retraso, pero una vez en la caché se puede responder con rapidez.
Una trampa en la operación es la dificultad de depurar en el borde. Como la ejecución en el borde procesa cada solicitud en una ubicación distinta, es difícil crear un entorno de ejecución reproducible. Un diseño de observabilidad que reúna en un solo lugar la agregación de registros de errores, las métricas y las trazas es lo que sostiene la operación. También hay casos en los que se adopta OpenTelemetry y se agrega en Datadog o Honeycomb.
El enrutamiento geográfico es una aplicación de la ejecución en el borde. Permite devolver destinos distintos para la misma URL corta según el país, el dispositivo o el idioma del usuario. Tiene usos como dirigir solo a los usuarios de la zona de la UE a otra página, devolver la página del producto en japonés a los usuarios que hablan japonés, o hacer un Deep Link a App Store en iOS y a Play Store en Android.
Los tres aspectos de latencia, coste y disponibilidad sirven de base para comparar las URLs cortas con computación en el borde frente a una configuración tradicional. La contrapartida de la consistencia, la depuración y los puntos de aprovechamiento del enrutamiento geográfico también son puntos de debate al elegir la configuración.