Diseña un Servicio de Acortamiento de URL

1) Requisitos funcionales Núcleo (MVP) - Crear URL corta - Entrada: long_url, alias_personalizado opcional, expiración opcional, id_usuario/clave_api opcional - Salida: short_url, key, created_at, expiry_at - Redirigir - GET /{key} -> 301/302 a long_url - Respetar expiración/estado deshabilitado - Analítica básica - Contar redirecciones por clave (total + cubos de tiempo) - Opcional: referente, país/región (grueso), familia de user-agent, tipo de dispositivo - Gestión de enlaces - Recuperar metadatos (long_url, created_at, expiry_at, status) - Deshabilitar/eliminar (eliminación lógica) Desearía tener - Dominios personalizados por cliente - API de acortamiento masivo - Generación de códigos QR - Comprobaciones anti-malware / navegación segura - Enrutamiento A/B, plantillas UTM No funcionales - Latencia de redirección muy baja (p95 < ~20–50ms desde el borde/caché) - Alta disponibilidad (múlti AZ/región) - No se requiere consistencia fuerte para la analítica, pero sí para el mapeo clave->URL 2) Arquitectura de alto nivel Flujo de tráfico - DNS -> CDN/Borde (opcional pero recomendado) - Balanceador de carga global (GSLB) -> Balanceador de carga L7 regional - Pasarela API - Autenticación (claves API/OAuth), limitación de velocidad, validación de solicitudes - Servicios de aplicación (sin estado) - Servicio de acortamiento (escrituras) - Servicio de redirección (lecturas, ruta extremadamente caliente) - Servicio de ingesta de analítica (asíncrono) Capa de datos - Almacén principal Clave-Valor para mapeo clave -> registro de destino - Capa de caché (Redis/Memcached) para búsquedas de claves calientes - Canalización de analítica - El Servicio de redirección emite eventos a un registro/cola (Kafka/PubSub/Kinesis) - El procesador de flujo agrega a un almacén OLAP (ClickHouse/BigQuery/Druid) y/o series temporales (Cassandra/Scylla) - Acumulaciones periódicas para paneles Servicios de soporte - Servicio de generación de claves (si se usan identificadores pregenerados) - Servicio de detección de abusos (reputación de URL, comportamiento del usuario) - Observabilidad: métricas, rastreo, registros Interacción - Crear: - Cliente -> Pasarela API -> Servicio de acortamiento - Validar URL, comprobar abuso, unicidad opcional del alias personalizado - Obtener clave única (estrategia de codificación a continuación) - Escribir mapeo en la base de datos - Invalidar/preparar caché - Redirigir: - Cliente -> CDN/Borde -> Servicio de redirección - Buscar clave en caché; en caso de error, consultar la base de datos - Si se encuentra y no está expirado/deshabilitado: responder 301/302 - Emitir evento de analítica asíncrono 3) Estrategia de codificación de URL Objetivos: unicidad, longitud corta, alto rendimiento, sin cuello de botella central. Recomendado: ID numérico + Base62 - Usar un ID de 64 bits monotónicamente creciente (o ordenado por tiempo) y codificar en Base62 (0-9a-zA-Z). - Para 100M de URL nuevas/mes (~3.86k escrituras/segundo en promedio; pico más alto), la generación de ID debe soportar > decenas de miles/segundo. Opciones: A) Secuencia de base de datos (simple) - Pros: fácil, fuertemente único - Contras: puede ser un cuello de botella y difícil entre fragmentos; requiere coordinación B) ID distribuido (tipo Snowflake) (recomendado) - 64 bits: marca de tiempo + región/nodo + secuencia - Pros: escalable, sin escritor único - Contras: claves ligeramente más largas si se codifica el 64 bits completo; aún compacto en Base62 (hasta 11 caracteres) C) Grupo de claves pregeneradas - El trabajo en segundo plano genera cadenas Base62 aleatorias, almacena el grupo no utilizado; la aplicación reserva claves. - Pros: desacopla del orden, puede mantener las claves cortas - Contras: complejidad de gestión del grupo Manejo de colisiones - Para el enfoque basado en ID: sin colisiones por construcción. - Para alias personalizados o claves aleatorias: forzar unicidad con escritura condicional/restricción única; en caso de colisión, reintentar con una nueva clave. Longitud de la clave - Longitud Base62 necesaria: 100M/mes implica ~1.2B/año. Base62^7 ≈ 3.5T, por lo que 7 caracteres es suficiente si se usan IDs secuenciales; los IDs de Snowflake pueden tener 10–11 caracteres pero son aceptables. 4) Diseño de la base de datos Requisitos del almacén principal - QPS de lectura muy alto, búsquedas basadas en claves, registros pequeños, baja latencia. - Escrituras fuertemente consistentes para la unicidad de claves; las lecturas pueden ser eventualmente consistentes si la caché es correcta, pero se prefiere la lectura consistente después de la escritura para enlaces nuevos. Recomendado: DynamoDB / Cassandra / ScyllaDB (NoSQL KV) O MySQL/Postgres con fragmentación. - Pros de NoSQL KV: escala horizontal, alto rendimiento, latencia predecible. - Pros de SQL: restricciones, transacciones, más simple para unicidad de alias personalizados y consultas de administración; pero la fragmentación/réplicas se vuelven más complejas a escala. Elección pragmática - Almacén de mapeo: DynamoDB (o Cassandra/Scylla) como sistema de registro. - Almacén relacional opcional para usuario/cuenta/facturación. Esquema principal (KV / columna ancha) Tabla: url_mapping - key (clave de partición, cadena) - long_url (cadena) - created_at (marca de tiempo) - expiry_at (marca de tiempo, nulo) - status (activo|deshabilitado|eliminado) - user_id (cadena/uuid, nulo) - custom_alias (booleano) - domain (cadena, predeterminado) - last_accessed_at (marca de tiempo, nulo) - redirect_code (int: 301/302) Patrones de acceso/índices - Principal: clave -> registro - Por usuario (para UI de gestión): índice secundario - GSI: id_usuario como clave de partición, created_at como clave de ordenación (o inversa) - Por long_url (desduplicación opcional): índice hash(long_url) (solo si desea el comportamiento "misma URL larga devuelve misma clave") Almacenamiento de analítica (separado) - Eventos brutos en almacenamiento de objetos (S3/GCS) + agregación en streaming a OLAP. - Ejemplo de tabla agregada (ClickHouse): (key, día/hora, redirecciones, unique_ips_approx, país, dominio_referente, familia_ua) Resumen de la compensación SQL vs NoSQL - SQL: unicidad más fácil para alias personalizados, consultas ad hoc; más difícil escalar escrituras/lecturas sin fragmentación cuidadosa. - NoSQL: mejor para la carga de trabajo de búsqueda principal; debe diseñar patrones de acceso con anticipación; la unicidad para alias personalizados se maneja mediante escrituras condicionales. 5) Escalabilidad y rendimiento Estimaciones de tráfico - Escrituras: 100M/mes ≈ 3.86k/s promedio, planificar para 10x pico => ~40k/s. - Lecturas: 100:1 => 386k/s redirecciones promedio, planificar para 10x pico => ~4M/s pico globalmente. Almacenamiento - 100M/mes * 12 = 1.2B mapeos/año. - Tamaño del registro (clave ~10B, URL promedio 200B, metadatos): suponer ~500B–1KB. - 1.2B * 1KB ≈ 1.2TB/año (más replicación e índices). Almacenamiento en caché - Clúster de Redis/Memcached por región. - Clave de caché: clave corta; valor: long_url + estado + expiry_at + redirect_code. - Estrategia de TTL: - Para enlaces que no expiran: TTL largo (ej. 1–7 días) con actualización al acceso. - Para enlaces que expiran: TTL alineado con la expiración. - Caché negativa para claves faltantes/deshabilitadas (TTL corto) para reducir los accesos a la base de datos. - Caché CDN/Borde para redirecciones seguras: - Caché 301 para enlaces públicos, no expirantes; cuidado con redirecciones por usuario o dinámicas. Fragmentación/particionamiento - NoSQL: particionar por clave; asegurar distribución uniforme. - Si es SQL: fragmentar por hash de clave; mantener capa de enrutamiento. Réplicas de lectura - Si se usa SQL o un almacén KV replicado: agregar réplicas de lectura para consultas de administración/lectura intensivas no de redirección. Claves calientes - URL cortas extremadamente populares pueden sobrecargar los nodos de caché. - Usar hash consistente con suficientes nodos virtuales. - Considerar caché LRU en memoria en el servicio de redirección. - La caché de borde en CDN reduce la carga del origen. Optimización de la ruta de escritura - Agrupar eventos de analítica; nunca bloquear la redirección por analítica. 6) Fiabilidad y disponibilidad Multi-AZ - Ejecutar servicios de API/Redirección en múltiples Zonas de Disponibilidad detrás del balanceador de carga. - Caché: clúster de Redis con replicación + failover automático (o Redis administrado). - BD: replicación multi-AZ; lecturas/escrituras de quórum según corresponda. Multi-región (recomendado para servicio global) - Redirecciones activo-activo: replicar la base de datos de mapeo entre regiones (tablas globales de DynamoDB / Cassandra multi-DC). - Las escrituras se pueden enrutar a la región más cercana; resolver conflictos: - Para claves basadas en ID, las colisiones son improbables; los alias personalizados requieren unicidad global; manejar enrutando la creación de alias personalizados a una "región de origen" por dominio o usando coordinación global fuertemente consistente (ruta poco común). Failover - Comprobaciones de estado + cambio de tráfico automatizado a través de GSLB. - Los servicios sin estado permiten escalar y reemplazar rápidamente. Copias de seguridad y DR - Copias de seguridad/instantáneas continuas del almacén de mapeo. - Almacenar registros de analítica brutos en almacenamiento de objetos duradero. Degradación elegante - Si la canalización de analítica está caída, continuar las redirecciones y almacenar eventos en búfer (retención de cola) o muestrear. - Si la caché está caída, el servicio de redirección recurre a la base de datos (esperar aumento de latencia, pero el servicio permanece funcional). 7) Limitación de velocidad y prevención de abusos Limitación de velocidad - Límites por clave API/usuario/IP para puntos finales de creación (cubo de tokens/cubo con fugas en la Pasarela API). - Límites separados y más altos para redirecciones; proteger contra inundaciones con CDN/WAF. Controles de abuso - Validación de URL: permitir esquemas (http/https), longitud máxima, bloquear rangos de IP internos (estilo SSRF) para componentes de vista previa/escaneo. - Detección de malware/phishing: - Integrar con feeds de Navegación Segura/reputación. - Escaneo asíncrono; opcionalmente estado "pendiente" hasta que el escaneo sea exitoso para usuarios no confiables. - Políticas de alias personalizados: palabras reservadas, filtro de groserías, políticas de marca registrada. - Detección de bots: heurísticas de huella digital del dispositivo, CAPTCHA para tráfico de creación sospechoso. - Protección contra redirecciones: - Reglas WAF, detección de anomalías en patrones de redirección. - Alertas de límite de redirección por clave; limitación temporal. Resumen de planificación de capacidad/rendimiento (aproximado) - Redirecciones pico: objetivo de unos pocos millones de solicitudes/segundo a nivel mundial. - La descarga de CDN + las cachés regionales deberían servir la mayoría (objetivo >95% de aciertos de caché para el conjunto caliente). - Las lecturas de la base de datos de origen deben minimizarse; diseñar para <5% de errores. - Escrituras: decenas de miles/segundo en pico; la generación de ID distribuida evita cuellos de botella centrales. - Crecimiento de datos: ~1.2B mapeos/año; planificar almacenamiento de varios TB con sobrecarga de replicación e indexación. Punto de partida de implementación (lista de componentes) - Pasarela API + Autenticación - Servicio de acortamiento - Servicio de redirección (optimizado, dependencias mínimas) - Clúster de caché de Redis por región - BD de mapeo (DynamoDB/Cassandra/Scylla) - Biblioteca/servicio de generador de ID (Snowflake) - Procesadores de flujo Kafka/Kinesis + almacén OLAP - Servicio de administración/administración + base de datos de usuario - Monitoreo/alertas + WAF/CDN

### 1. Requisitos Funcionales * **Funcionalidad Principal**: * **Acortamiento de URL**: Los usuarios pueden enviar una URL larga y recibir una URL única y más corta. * **Redirección de URL**: El acceso a una URL corta redirigirá al usuario a la URL larga original con una redirección 301 (permanente). * **Funciones Extendidas**: * **URLs Personalizadas**: Los usuarios pueden elegir un alias personalizado para su URL corta (por ejemplo, `short.co/mi-evento`). * **Expiración de URL**: Los usuarios pueden establecer una hora/fecha de expiración para una URL corta, después de la cual ya no redirigirá. * **Analíticas**: El servicio rastreará métricas básicas para cada enlace, como clics totales, referentes y ubicación geográfica de los clics. * **Acceso a API**: Una API REST estará disponible para que los desarrolladores integren el servicio de acortamiento en sus aplicaciones. * **Cuentas de Usuario**: Los usuarios registrados pueden administrar sus enlaces, ver analíticas y acceder a límites de tasa de API más altos. ### 2. Arquitectura de Alto Nivel El sistema está diseñado para ser altamente disponible y escalable, con una clara separación de las rutas de lectura y escritura. 1. **Balanceador de Carga (LB)**: Distribuye el tráfico entrante entre múltiples servidores web para evitar que un solo servidor sea un cuello de botella. Maneja la terminación SSL. 2. **Servidores Web/API**: Un conjunto de servidores sin estado que ejecutan la lógica de la aplicación. Manejan dos solicitudes principales: * `POST /api/v1/url` (Ruta de escritura): Crea una nueva URL corta. * `GET /{short_key}` (Ruta de lectura): Redirige a la URL larga. 3. **Servicio de Generación de Claves (KGS)**: Un microservicio dedicado responsable de generar claves cortas y únicas. Pre-genera claves y las almacena en una cola para garantizar baja latencia para la ruta de escritura. 4. **Caché**: Una caché distribuida en memoria (por ejemplo, Redis Cluster) se sitúa entre los servidores de aplicaciones y la base de datos. Almacena las correspondencias de `short_key` a `long_url` para enlaces accedidos frecuentemente para servir redirecciones con latencia muy baja. 5. **Base de Datos**: El almacén de datos principal para todas las correspondencias de URL y datos de usuario. 6. **Pipeline de Analíticas**: Los eventos de redirección se publican en una cola de mensajes (por ejemplo, Kafka). Un servicio separado consume estos eventos, agrega datos y los almacena en un almacén de datos (por ejemplo, ClickHouse o AWS Redshift) para consultas analíticas. **Flujo de Interacción (Redirección)**: `Cliente` -> `Balanceador de Carga` -> `Servidor API` -> `Caché (Redis)`. Si hay un acierto en caché, devuelve la redirección. Si hay un fallo en caché, -> `Base de Datos` -> `Servidor API` -> `Cliente`. La correspondencia se escribe luego en la caché para solicitudes subsiguientes. ### 3. Estrategia de Codificación de URL Usaremos una estrategia de **codificación Base62** combinada con un generador de ID único. * **Enfoque**: El Servicio de Generación de Claves (KGS) administrará un contador global de 64 bits (por ejemplo, utilizando una secuencia dedicada de base de datos SQL, Zookeeper o un servicio personalizado). * **Proceso**: 1. Cuando un servidor de aplicaciones necesita crear un enlace, solicita un ID único al KGS. 2. El KGS proporciona un número único (por ejemplo, `10001`). 3. El servidor de aplicaciones convierte este número a una cadena Base62 (`[a-zA-Z0-9]`). Por ejemplo, `10001` en Base62 es `2k1`. 4. Para garantizar una longitud fija y evitar claves cortas y adivinables, podemos usar una longitud de 7 caracteres. Un contador de 64 bits proporciona identificaciones únicas más que suficientes (2^64), que se pueden mapear a una cadena Base62. Una cadena Base62 de 7 caracteres puede representar 62^7 (~3.5 billones) de URL únicas, lo cual es suficiente para nuestra escala. * **Manejo de Colisiones**: Este enfoque garantiza la unicidad, por lo que las colisiones son imposibles por diseño. Esto es superior a hashear la URL larga, que puede producir colisiones y requiere verificaciones adicionales. ### 4. Diseño de la Base de Datos Dada la masiva producción de lectura y los requisitos de escalabilidad, una **base de datos NoSQL** como Apache Cassandra o Amazon DynamoDB es la opción ideal. * **¿Por qué NoSQL?**: El patrón de acceso principal es una simple búsqueda de clave-valor (`short_key` -> `long_url`). Las bases de datos NoSQL se destacan en escalabilidad horizontal, alta disponibilidad y lecturas de baja latencia para este patrón, lo que es perfecto para nuestra relación de lectura/escritura de 100:1. * **Compromiso SQL**: Una base de datos SQL fragmentada (por ejemplo, PostgreSQL con Citus) podría funcionar pero introduciría más complejidad operativa para la fragmentación y escalado a este nivel. **Esquema de Tabla Principal (tipo Cassandra/DynamoDB)**: * **Nombre de Tabla**: `urls` * **Clave Primaria**: `short_key` (Servirá como clave de partición, asegurando que los datos se distribuyan uniformemente en el clúster). * **Columnas**: * `short_key` (texto, Clave de Partición) * `long_url` (texto) * `user_id` (uuid) * `created_at` (timestamp) * `expires_at` (timestamp) - Podemos establecer un Tiempo de Vida (TTL) en la fila basado en este valor para la limpieza automática. ### 5. Escalabilidad y Rendimiento * **Estimaciones de Capacidad**: * **Escrituras**: 100M de URL/mes ≈ 40 escrituras/seg (promedio). * **Lecturas**: 10B de lecturas/mes ≈ 3,850 lecturas/seg (promedio). El tráfico pico podría ser 10-20 veces esta cantidad. * **Almacenamiento**: 100M de URL/mes * 12 meses * 5 años = 6B de URL. Con ~500 bytes por entrada, son ~3 TB de datos. * **Escalado de la Ruta de Lectura**: * **Caché**: Este es el componente más crítico. Usaremos una caché de múltiples capas. * **Caché CDN**: Utilizar una CDN (por ejemplo, Cloudflare) para almacenar en caché las redirecciones en el borde. Esto puede descargar un porcentaje significativo del tráfico para enlaces populares. * **Caché Distribuida**: Se utilizará una caché en memoria como Redis. Con 10B de lecturas/mes, muchas URL estarán 'calientes'. Almacenar en caché incluso el 10-20% de las URL más activas puede reducir la carga de lectura de la base de datos en más del 80-90%. * **Fragmentación de Base de Datos**: Nuestra elección de NoSQL con `short_key` como clave de partición maneja esto de forma natural. Podemos añadir más nodos al clúster de base de datos para escalar tanto el almacenamiento como la producción horizontalmente. ### 6. Fiabilidad y Disponibilidad * **Redundancia**: Todos los componentes se desplegarán en múltiples Zonas de Disponibilidad (AZs). * **Balanceadores de Carga, Servidores API**: Desplegados en un grupo de escalado automático en al menos dos AZs. * **Caché (Redis)**: Desplegada en una configuración de clúster con réplicas en diferentes AZs. * **Base de Datos (Cassandra)**: La base de datos se configurará con un factor de replicación de 3, con réplicas almacenadas en diferentes AZs para garantizar la durabilidad de los datos y la disponibilidad durante un fallo de AZ. * **Conmutación por Error**: Se implementarán mecanismos de conmutación por error automatizada. El balanceador de carga dirigirá automáticamente el tráfico lejos de las instancias no saludables. Los servicios de bases de datos administrados suelen manejar la conmutación por error de bases de datos automáticamente. * **Copia de Seguridad de Datos**: Se tomarán instantáneas regulares de la base de datos y se almacenarán en una región separada para la recuperación ante desastres. ### 7. Límites de Tasa y Prevención de Abusos * **Límites de Tasa**: Implementados en la Pasarela API o en la lógica de la aplicación utilizando un almacén en memoria como Redis. * Los límites se basarán en la dirección IP para usuarios anónimos (por ejemplo, 10 creaciones/minuto) y en la clave API para usuarios registrados (con diferentes niveles). * **Prevención de Abusos**: * **Escaneo de URL maliciosas**: Integración con un servicio como la API de Navegación Segura de Google para verificar cada `long_url` enviada contra una lista negra de sitios maliciosos. * **CAPTCHA**: Para usuarios anónimos que muestran patrones de envío de alta frecuencia. * **Lista Negra**: Mantener una lista negra interna de dominios y cuentas de usuario conocidos por spam.