Diseño de sistema de acortador de URL: cómo funcionan los acortadores de enlaces bajo el capó

"Diseña un acortador de URL" es una de las preguntas más populares en entrevistas de diseño de sistemas — y por una buena razón. Toca hashing, bases de datos, caché, equilibrio de carga y sistemas distribuidos, todo en un producto engañosamente simple.

En esta guía, recorreremos cómo funcionan realmente los acortadores de URL, las decisiones clave de diseño y los compromisos involucrados a escala.

Un acortador de URL hace dos cosas:

1. 1Acortar: Tomar una URL larga y generar un código corto
2. 2Redirigir: Cuando alguien visita la URL corta, redirigirlo a la original

Aquí está el flujo de alto nivel:

El usuario crea un enlace corto:
  URL larga → Generar código corto → Almacenar mapeo → Devolver URL corta

El usuario hace clic en el enlace corto:
  URL corta → Buscar código → Encontrar URL larga → Redirección 301

El desafío central es generar códigos únicos y cortos. Hay varios enfoques:

Convierte un ID con incremento automático a una cadena Base62 usando caracteres [a-zA-Z0-9]:

• ID 1 → 1
• ID 62 → 10
• ID 238,328 → ZZZ

Un código Base62 de 7 caracteres admite 62^7 = 3.5 billones de URLs únicas.

Ventajas: Simple, longitud predecible, sin colisiones Desventajas: Los IDs secuenciales son predecibles (los usuarios pueden adivinar otras URLs cortas)

Aplica una función hash (MD5, SHA-256) a la URL larga y toma los primeros N caracteres:

SHA256("https://example.com/very/long/url") → "a3f2b8c1..." Código corto: "a3f2b8c"

Ventajas: La misma entrada siempre produce la misma salida (deduplicación) Desventajas: Las colisiones de hash requieren manejo; la longitud de hash fija puede desperdiciar espacio

Genera una cadena alfanumérica aleatoria y verifica la unicidad:

Ventajas: Simple, impredecible Desventajas: Requiere verificación de colisiones en cada creación; se ralentiza a medida que la base de datos se llena

La mayoría de los sistemas en producción usan codificación Base62 con un generador de ID distribuido. Es simple, libre de colisiones y eficiente. En Linkly, usamos un enfoque similar — puedes leer más sobre cómo funcionan los acortadores de URL para una descripción general menos técnica.

La tabla principal es sencilla:

urls ├── id (clave primaria, incremento automático) ├── short_code (índice único) ├── long_url (el destino) ├── created_at (marca de tiempo) ├── user_id (quién lo creó) └── click_count (contador desnormalizado)

SQL (PostgreSQL, MySQL): Cumplimiento ACID, consistencia fuerte, bueno para escala moderada. La mayoría de los acortadores de URL comienzan aquí.

NoSQL (DynamoDB, Cassandra): Mejor escalado horizontal para miles de millones de URLs. La consistencia eventual es aceptable para este caso de uso.

Híbrido: SQL para mapeos de URL (necesita consistencia fuerte para redirecciones), NoSQL o una base de datos de series de tiempo para análisis de clics (alto volumen de escritura, la consistencia eventual está bien).

Cuando un usuario hace clic en un enlace corto, el sistema debe:

1. 1Analizar el código corto de la URL
2. 2Buscar la URL larga correspondiente
3. 3Devolver una respuesta de redirección HTTP

• 301 (Permanente): El navegador almacena en caché la redirección. Menos solicitudes del servidor, pero pierdes visibilidad de los clics repetidos.
• 302 (Temporal): El navegador verifica con el servidor cada vez. Más solicitudes, pero mejor seguimiento de clics.

La mayoría de los acortadores de URL usan redirecciones 302 para precisión en el seguimiento de clics, luego ofrecen 301 como una opción para casos de uso de SEO. Consulta nuestra guía sobre redirecciones 301 para obtener más información sobre esta distinción.

Las redirecciones deben ser rápidas — cada milisegundo de latencia afecta la experiencia del usuario. El almacenamiento en caché es crítico:

Almacena en caché el mapeo short_code → long_url en memoria:

GET /abc123 → Verificar Redis para "abc123" → ¿Acierto en caché? Devolver redirección inmediatamente → ¿Fallo en caché? Consultar base de datos, almacenar en caché resultado, devolver redirección

Una pequeña instancia de Redis puede almacenar en caché millones de mapeos de URL. Dado que la mayoría del tráfico va a un número relativamente pequeño de enlaces populares, las tasas de acierto de caché superiores al 90% son comunes.

Para redirecciones 301, los nodos perimetrales de CDN pueden almacenar en caché la respuesta de redirección, sirviéndola desde la ubicación más cercana al usuario sin golpear el servidor de origen en absoluto.

Registrar datos de clics es una operación con mucho volumen de escritura que no debe ralentizar la redirección:

1. 1El usuario hace clic en el enlace corto
2. 2El sistema devuelve inmediatamente la redirección
3. 3El evento de clic se envía a una cola de mensajes (Kafka, RabbitMQ, SQS)
4. 4Un trabajador de fondo procesa el evento: analiza el agente de usuario, geolocaliza IP, almacena análisis

Esto desacopla la ruta de redirección rápida del proceso analítico más lento.

• Marca de tiempo
• Dirección IP (para geolocalización)
• Agente de usuario (para detección de dispositivo/navegador)
• Encabezado referer
• País, ciudad (de geolocalización IP)

Los acortadores de URL son extremadamente pesados en lectura. Una proporción típica podría ser 100:1 lecturas a escrituras. Esto significa:

• Optimiza la ruta de redirección por encima de todo
• Usa almacenamiento en caché agresivamente
• Replicas de lectura para la base de datos

Si usas IDs con incremento automático en múltiples servidores, necesitas evitar colisiones. Opciones:

• Snowflake IDs: El enfoque de Twitter — incrusta marca de tiempo, ID de máquina y número de secuencia
• UUID: Universalmente único pero más largo
• Rangos de ID: Asigna a cada servidor un rango de IDs para asignar

Implementa servidores de redirección en múltiples regiones. Un usuario en Tokio no debería necesitar un viaje de ida y vuelta a un servidor en Virginia para una redirección.

Los acortadores de URL pueden ser abusados para phishing y distribución de malware. Los sistemas en producción necesitan:

• Escaneo de URL — verifica los destinos contra bases de datos de malware y phishing
• Limitación de velocidad — evita la creación masiva de enlaces cortos maliciosos
• Informes de abuso — permite a los usuarios informar sobre enlaces sospechosos
• Páginas de vista previa — opcionalmente muestra a los usuarios a dónde va un enlace antes de redirigir

Obtén más información sobre seguridad de enlaces y protección contra fraude de clics.

Más allá del acortamiento y redirección básicos, los acortadores de URL en producción agregan:

• Dominios personalizados — enlaces cortos de marca usando tu propio dominio
• Slugs personalizados — elige tu propio código corto en lugar de caracteres aleatorios
• Expiración — enlaces con límite de tiempo que dejan de funcionar después de una fecha
• Protección con contraseña — requiere una contraseña para acceder al destino
• Pruebas A/B — rotar entre múltiples destinos
• Geo-targeting — redirigir por país
• Targeting de dispositivo — diferentes destinos para móvil vs. escritorio
• Códigos QR — generar códigos escaneables para cualquier enlace corto

El diseño de sistema de acortador de URL es un gran ejercicio porque comienza simple pero revela capas de complejidad: generación de códigos, diseño de bases de datos, caché, canalizaciones de análisis y prevención de abuso. Comprender estos fundamentos ayuda ya sea que te estés preparando para entrevistas o construyendo tus propias herramientas.

¿Quieres usar un acortador de URL en producción sin construir uno? Comienza con Linkly — toda la arquitectura descrita arriba, lista para usar con dominios personalizados, análisis y características avanzadas.