Abre elido.me/abc123 y algo tiene que convertir esa cadena corta en una dirección web completa antes de que tu navegador pueda cargar algo. El mecanismo es más simple de lo que la mayoría asume. Un acortador de URL almacena un mapeo de un código corto a una URL de destino larga. Cuando haces clic en el enlace corto, el servicio trata el código como una clave de búsqueda, encuentra el destino y devuelve una redirección HTTP que le dice a tu navegador adónde ir realmente. Una solicitud de entrada, una redirección de salida.
Esa es toda la idea. Todo lo demás es ingeniería alrededor de tres presiones: hacer la búsqueda rápida, mantener los códigos cortos y únicos, y registrar el clic sin ralentizar a nadie. Esta publicación explica cómo funcionan los acortadores de URL de principio a fin, usando la arquitectura de borde de Elido como ejemplo concreto mientras se mantiene la explicación válida para los acortadores en general. Cubriremos el mapeo de slug a URL, cómo se generan los códigos cortos, dónde viven los datos, la elección de redirección 301 versus 302 que confunde a más personas que cualquier otra cosa, cómo es realmente una redirección HTTP en la red, por qué importa el almacenamiento en caché en el borde y cómo se cuenta un clic de forma asíncrona.
Cómo funcionan los acortadores de URL: el mapeo en el centro#
Quita la infraestructura y un acortador de URL es un almacén de clave-valor con un manejador de redirección incorporado. La clave es el slug, el código corto después del dominio. El valor es el destino, la URL larga que pegaste originalmente.
Cuando creas un enlace corto, el acortador escribe una fila: este slug apunta a ese destino. Cuando alguien visita el enlace corto, el acortador lee esa fila y actúa sobre ella. Crear enlaces es raro; leerlos es constante. Un solo enlace de marketing puede escribirse una vez y luego leerse cientos de miles de veces a lo largo de su vida. Esa proporción de lecturas intensivas es el hecho más importante sobre la carga de trabajo, y da forma a cada decisión de diseño que sigue, especialmente el almacenamiento en caché.
El mapeo en sí puede contener más que un destino. En Elido, un slug puede tener reglas de segmentación, de modo que un enlace corto dirige a diferentes destinos según el país, dispositivo, idioma o tiempo. Eso es lo que llamamos un smart link, y sigue siendo la misma búsqueda, solo con una pequeña evaluación de reglas después de la lectura. La relación central nunca cambia: slug de entrada, destino de salida.
Generar el código corto#
Si el slug es la clave, ¿de dónde viene? Hay dos enfoques bien establecidos, y la mayoría de los acortadores usan uno o una combinación de ambos.
El primero es la codificación base62 de un ID de base de datos. Cada nuevo enlace obtiene un ID entero autoincremental de la base de datos. Codificas ese entero en base62, que utiliza los 62 caracteres seguros para URL a-z, A-Z y 0-9. El ID 1 se convierte en b, el ID 125 en un código de dos caracteres, y así sucesivamente. Base62 es denso: tres caracteres cubren unos 238.000 enlaces, cinco caracteres cubren aproximadamente 916 millones, seis cubren unos 56 mil millones. Los códigos se mantienen cortos y, como se asignan uno a uno a IDs únicos, nunca colisionan. La contrapartida es que los IDs secuenciales son predecibles, por lo que muchos sistemas mezclan u desplazan el espacio de IDs antes de codificar.
El segundo enfoque es la generación aleatoria. Elige una cadena aleatoria de longitud fija del mismo alfabeto, luego comprueba la base de datos para confirmar que no está ya tomada. Si colisiona, genera otra. Las colisiones son extremadamente raras en longitudes sensibles, por lo que el bucle de reintento casi nunca se ejecuta. Los slugs aleatorios no son enumerables, lo que es el argumento de seguridad a su favor.
Los slugs personalizados, los de marca como elido.me/spring-sale, se sitúan encima de cualquiera de los esquemas. El usuario proporciona la cadena; el acortador la valida para los caracteres permitidos y comprueba la unicidad contra el mismo índice antes de guardar. Ya sea que el slug se genere o se elija a mano, termina en el mismo lugar: una columna única en el almacén de datos.
Dónde viven los datos#
El mapeo de slug a destino necesita un hogar que pueda responder "¿a qué apunta este slug?" de forma rápida y consistente. Para la fuente de verdad, ese hogar es casi siempre una base de datos relacional. Elido usa Postgres, con el slug almacenado como columna indexada única para que una búsqueda sea una sola lectura con clave en lugar de un escaneo de tabla. Postgres contiene el registro canónico de cada enlace, usuario y workspace.
Pero acceder a Postgres en cada clic individual sería un desperdicio dada la proporción de lecturas intensivas. Una búsqueda de slug con clave en Postgres normalmente se ejecuta en uno a tres milisegundos, lo que suena rápido hasta que lo multiplicas por el volumen de clics de un enlace viral y recuerdas que una conexión de base de datos es un recurso finito. Por eso los acortadores en producción ponen una caché delante de la base de datos. La caché es donde realmente se sirven la mayoría de las lecturas; la base de datos es el respaldo para lo que la caché no tiene todavía.
Elido ejecuta una caché de dos niveles delante de Postgres. El primer nivel es una caché LRU en proceso que vive dentro del propio binario de redirección, que devuelve un destino en unos pocos cientos de nanosegundos sin ningún salto de red en absoluto. El segundo nivel es un clúster Redis en la misma región, que sirve en menos de un milisegundo. Solo un fallo frío, un slug que ninguno de los dos niveles ha visto recientemente, cae hasta una llamada gRPC de origen contra api-core, que lee Postgres. La tasa de aciertos combinada entre ambos niveles de caché ronda el 99,4%, por lo que la base de datos se toca aproximadamente en una de cada 167 solicitudes. El desglose completo de cómo se comporta esa caché, incluyendo su política de desalojo y los modos de fallo que hemos encontrado, está en nuestra descripción de estrategia de caché.
Qué es realmente una redirección HTTP#
Una vez que el acortador tiene el destino, tiene que devolvérselo al navegador. Lo hace con una redirección HTTP, que es solo un tipo específico de respuesta. En lugar de devolver contenido de página con un 200 OK, el servidor devuelve un código de estado 3xx y un encabezado Location que nombra la URL real. En la red la respuesta es pequeña:
HTTP/1.1 302 Found
Location: https://shop.example.com/spring-collection
Content-Length: 0
El navegador lee el código de estado, ve un encabezado Location e inmediatamente emite una nueva solicitud a esa dirección. Para la persona que hace clic, parece una sola navegación; por debajo son dos solicitudes, con el enlace corto actuando como una búsqueda rápida de directorio en el medio. La semántica de cada código 3xx está definida en RFC 7231, y la guía de redirecciones HTTP de Mozilla es la referencia práctica más clara sobre qué hace cada código.
El cuerpo está vacío porque no hay nada que renderizar. La carga útil completa es la línea de estado y el encabezado. Esta es parte de la razón por la que las redirecciones son baratas de servir: no hay plantilla, no hay unión de base de datos para el contenido, no hay marcado. Resuelve el slug, establece un encabezado, envía.
301 vs 302: la elección que decide tus análisis#
Aquí es donde los acortadores toman silenciosamente una decisión que la mayoría de los usuarios nunca ven pero que determina si su enlace es editable y rastreable. El código de estado de redirección no es una formalidad. Las dos opciones comunes se comportan de manera muy diferente.
Un 301 Movido Permanentemente le dice al navegador, y a cada proxy y CDN entre tú y el servidor, que este enlace corto siempre apuntará al mismo lugar. Así que lo almacenan en caché. Un 301 se guarda de forma agresiva. La próxima vez que el visitante haga clic en ese enlace corto, su navegador puede resolverlo desde la caché y nunca ponerse en contacto con el acortador en absoluto. Eso es genial para ahorrar un viaje de ida y vuelta, y es un desastre para una herramienta de enlaces, porque dos cosas se rompen. Primero, los análisis quedan ciegos: los clics servidos desde la caché del navegador nunca llegan a tu servidor, por lo que nunca se cuentan. Segundo, el destino queda efectivamente congelado. Si cambias a dónde apunta el enlace, cualquiera que ya haya almacenado el 301 en caché seguirá aterrizando en la dirección antigua hasta que su caché caduque, lo que tú no controlas.
Un 302 Found (y su primo más estricto 307 Temporary Redirect) le dice al navegador que esto es temporal: vuelve y pregunta de nuevo la próxima vez. El navegador no almacena el mapeo en caché, por lo que cada clic vuelve a solicitar el enlace corto al servidor. Ese viaje de red adicional es exactamente lo que quiere una herramienta de enlaces. Cada clic llega a tu infraestructura, por lo que cada clic es contable, y como el servidor resuelve el destino de nuevo cada vez, puedes cambiar adónde apunta un enlace y hacer que el nuevo objetivo surta efecto en el siguiente clic. El costo es un viaje de red de ida y vuelta por clic, que un borde bien construido mantiene en los milisegundos de un solo dígito.
Por eso Elido usa 302 por defecto. Los destinos editables y los datos de clics precisos son el punto central de un enlace gestionado, y un 301 sacrifica ambos por una optimización de caché que normalmente no quieres. RFC 7231 especifica que un 301 es cacheable por defecto mientras que un 302 no se almacena a menos que los encabezados lo indiquen, que es precisamente el comportamiento que los dos casos de uso requieren. Hay casos particulares donde una redirección permanente es correcta, una migración de dominio real, por ejemplo, pero para enlaces cortos rastreables y editables la redirección temporal es el valor predeterminado correcto.
Almacenamiento en caché en el borde para baja latencia#
Una redirección es síncrona y bloqueante. El navegador del visitante se detiene en el enlace corto hasta que llega la redirección, y solo entonces puede comenzar a cargar la página que realmente importa. Cada milisegundo empleado en resolver el slug es un milisegundo añadido a la espera del visitante. Por eso los acortadores serios acercan la búsqueda al visitante tanto como sea posible.
Elido ejecuta el manejador de redirección en puntos de presencia de borde en Fráncfort, Ashburn y Singapur, con el tráfico enrutado al más cercano. El manejador está escrito en Go sobre fasthttp, elegido porque su ruta de solicitud sin asignación mantiene las pausas de recolección de basura predecibles bajo carga sostenida. Combinado con la caché en memoria, esto mantiene las redirecciones a un p95 por debajo de 15ms en un resultado de caché, medido en el POP: aproximadamente 4,8ms mediana en Fráncfort, subiendo a unos 14ms p95 en Singapur donde la geografía es más amplia. La mayor parte de ese presupuesto es tránsito de red físico, la distancia inevitable entre el visitante y el POP más cercano, que es la parte que no puedes optimizar en software. Documentamos el presupuesto completo de latencia y cómo mide cada región en la publicación sobre p95 bajo 15ms.
Poner la búsqueda en el borde en lugar de en un solo servidor central es la diferencia entre una redirección que se siente instantánea y una que añade una pausa visible. También es por eso que el enrutamiento de borde anycast supera a una configuración solo con DNS para esta carga de trabajo, una comparación que exploramos en POPs de borde versus enrutamiento solo con DNS. La versión corta: la red hace la geografía y la caché hace la velocidad.
Contar el clic sin ralentizar la redirección#
Un acortador que solo redirigiera sería un servicio de redirección. Lo que lo convierte en una herramienta de gestión de enlaces es que cuenta cada clic y te dice quién hizo clic, desde dónde, en qué dispositivo. La parte difícil es hacerlo sin hacer esperar al visitante.
La respuesta es desacoplar los dos por completo. Cuando el manejador de redirección resuelve un slug, envía la respuesta 302 de inmediato. Registrar el clic ocurre después, como trabajo fire-and-forget. El manejador añade un evento de clic (slug, marca de tiempo, una IP truncada, un hash del user-agent) a una cola de mensajes y sigue adelante. No espera a que se confirme la escritura. Si la cola no está disponible brevemente, el clic se descarta en lugar de retrasar la redirección; tomamos la decisión deliberada de que perder un clic en caso de fallo de infraestructura es aceptable y fallar una redirección no lo es.
Elido usa Redpanda como esa cola. Un consumidor separado, el ingestor de clics, lee los eventos de la cola y los escribe en ClickHouse, una base de datos columnar construida para el tipo de carga de trabajo de alta volumetría de adición y agregación que es la analítica de clics. La redirección del visitante ya se completó milisegundos antes; la fila de análisis llega unos segundos después, completamente fuera de la ruta caliente. Explicamos el diseño de la cola en ingestión de clics fire-and-forget y por qué un almacén columnar supera a Postgres para esto en por qué usamos ClickHouse para la analítica de clics.
Este desacoplamiento es la razón por la que tus análisis pueden ser detallados sin ser lentos. La ruta de redirección se mantiene ligera porque ningún conteo, puntuación ni agregación ocurre mientras el visitante espera.
Poniéndolo todo junto#
Un acortador de URL, de principio a fin, es una secuencia corta. Creas un enlace y el acortador almacena un mapeo de slug a destino en Postgres, generando o validando el slug como clave única. Un visitante hace clic, la solicitud llega al POP de borde más cercano y el manejador resuelve el slug desde una caché en memoria, cayendo a Redis y luego a la base de datos solo en un fallo. Devuelve un 302 con el destino en el encabezado Location, para que el clic sea contable y el destino permanezca editable. Luego dispara el evento de clic a una cola para que un consumidor separado lo almacene, sin hacer esperar a nadie.
Cada pieza es individualmente simple. La ingeniería está en las proporciones y los presupuestos: una carga de trabajo de lecturas intensivas que quiere una caché, un techo de latencia que quiere el borde, y un requisito de análisis que quiere mantenerse fuera de la ruta caliente. Si quieres construir sobre esto directamente, la función de Smart Links expone la capa de reglas, la API y SDKs te permiten crear enlaces desde código, y la página de soluciones para desarrolladores y la documentación de arquitectura de edge-redirect profundizan en las partes móviles. Si estás evaluando una herramienta en lugar de construir una, nuestros escritos sobre qué es un acortador de URL y si los acortadores de URL son seguros cubren el terreno desde el lado del usuario, y la página de precios explica dónde termina el nivel gratuito.