Diseñar un servicio de acortamiento de URLs a escala

Arquitectura de alto nivel (diagrama textual y componentes) - Clientes: navegadores web, aplicaciones móviles. Acceden a URLs cortas (short.example/abc1234) y a la API de escritura para crear URLs cortas. - CDN / Edge (CloudFront, Fastly): Capa de borde que recibe las solicitudes de URL cortas entrantes. El borde almacenará en caché las respuestas de redirección (HTTP 301/302) y las servirá sin tocar el origen siempre que sea posible para cumplir con el SLA de latencia. - Enrutamiento de borde / DNS global (Route53, anycast): Dirige las llamadas a la API de escritura a la región más cercana y los accesos a URL cortas al borde/región más cercana. Se configuran comprobaciones de estado y conmutación por error. - Puerta de enlace API regional + Balanceador de carga (API Gateway / ALB): Acepta escrituras de clientes y llamadas de gestión. Dirige a los Servicios de Escritura desplegados en contenedores (ECS/Kubernetes) a través de las zonas de disponibilidad. - Servicio de Escritura (microservicio sin estado): Valida la entrada, genera un token corto a través del módulo generador de ID, escribe el mapeo en la base de datos principal, publica eventos en el flujo, actualiza las cachés y devuelve la URL corta. - Servicios de Ruta de Lectura / Servicio de Redirección (sin estado): Recibe fallos de caché del borde o accesos directos, consulta la caché local (clúster Redis), recurre a la base de datos, devuelve la redirección con las cabeceras de caché apropiadas. - Caché distribuida (clústeres Redis por región, agrupados/replicados): Las búsquedas en caliente se almacenan aquí para respuestas de microsegundos. Cada región tiene su propio clúster Redis con replicación entre AZ. - Almacenamiento principal (DynamoDB o alternativa Cassandra/Scylla): Almacena el mapeo short_id -> long_url, metadatos, caducidad, propietario, ts de creación. Elegido por su alto rendimiento de lectura/escritura, soporte TTL y replicación multirregión. - Flujo de eventos (Kinesis / Kafka): Todas las escrituras producen eventos para análisis, actualizaciones de índices, mensajes de invalidación de caché y procesamiento asíncrono. - Trabajadores en segundo plano (contenedores): Manejan la limpieza de TTL, la cola de recuperación, los análisis y las comprobaciones de replicación asíncrona. - Monitorización y Operaciones: Prometheus/Grafana, CloudWatch, alertas, runbooks automatizados. Interacciones de componentes (lectura): El usuario accede a la URL corta -> La caché del borde comprueba la redirección en caché -> si se encuentra, devuelve la redirección en caché (<5 ms). Si no se encuentra, el borde reenvía al balanceador de carga regional -> El Servicio de Redirección consulta la caché Redis -> si se encuentra, devuelve la redirección y el borde la almacena en caché; si no se encuentra, el Servicio de Redirección consulta la base de datos principal -> devuelve la redirección -> se establece Redis y el borde almacena en caché la redirección. Interacciones de componentes (escritura): El cliente llama a la API -> API Gateway -> Servicio de Escritura -> El generador de ID produce el token -> El Servicio de Escritura escribe el mapeo en la base de datos principal con TTL -> El Servicio de Escritura publica el evento en el flujo -> El Servicio de Escritura escribe en la caché Redis y devuelve la URL corta. Los trabajadores en segundo plano replican asíncronamente los eventos a los análisis y a otras regiones según sea necesario. Algoritmo de acortamiento de URL y estrategia de generación de claves Objetivos: token alfanumérico máximo de 7 caracteres, no adivinable (sin tokens secuenciales), baja probabilidad de colisión, comportamiento de fallo/reintento reproducible. Espacio y restricciones: 62^7 ~= 3.52e12 tokens posibles. El objetivo mensual de 100 millones de tokens nuevos es minúsculo en comparación con el espacio, pero debemos asegurarnos de que no haya una enumeración fácil. Estrategia elegida (principal): - Usar generación aleatoria criptográficamente segura por cada URL corta nueva. Generar un entero aleatorio de 64 bits criptográficamente seguro, aplicar muestreo por rechazo para mapear al rango [0, 62^7 - 1] sin sesgo de módulo, luego codificar en base62 en exactamente 7 caracteres. Esto produce tokens uniformemente aleatorios en el espacio de 7 caracteres y sin secuencialidad. - Antes de confirmar, intentar una inserción atómica en la base de datos con short_id como clave primaria y unicidad forzada. Si la inserción falla debido a una colisión rara, reintentar con un nuevo token aleatorio (probabilidad de colisión esperada insignificante; reintentos esperados << 1). Por qué no IDs secuenciales o codificación biyectiva de un contador creciente: los IDs secuenciales o derivados de marca de tiempo son adivinables y permiten la enumeración y el scraping. Los rechazamos para cumplir con el requisito de no ser adivinables. Alternativa considerada y rechazada: hashes criptográficos truncados de la URL larga (por ejemplo, los primeros 7 caracteres base62 de SHA256). Rechazado porque el mapeo determinista hace que los tokens sean adivinables si el atacante puede hashear URLs populares; también las colisiones son más frecuentes al truncar. Podríamos haber usado HMAC(longURL, secret) para ser determinista y no adivinable, pero el mapeo determinista impide reutilizar tokens cortos en múltiples variaciones de entrada y complica el TTL/revocación. Esquema de base de datos y tecnología de almacenamiento (con justificación) Almacén principal elegido: DynamoDB (AWS) o Cassandra/Scylla administrado si se autoaloja. Razón principal: administrado, escalable horizontalmente, alto rendimiento de lectura/escritura, soporte TTL incorporado, replicación multirregión (Tablas Globales de DynamoDB) y acceso de un solo dígito de milisegundos si se aprovisiona adecuadamente. Esto es importante para un tiempo de actividad del 99,9% y operaciones sencillas. Esquema (lógico, estilo DynamoDB): - Tabla: url_map - Clave de partición: short_id (cadena, 7 caracteres) - Atributos: long_url (cadena), created_at (marca de tiempo), expires_at (marca de tiempo), owner_id (cadena), metadata (blob JSON), version (int), deleted (booleano), deletion_marked_at (marca de tiempo), click_count (numérico, opcional), analytics_shard_id (para fragmentación de clics) - Atributo TTL: expires_at para caducidad automática por la función TTL de la base de datos Índices: no se requieren índices secundarios globales adicionales para la ruta de redirección. Opcionalmente, un GSI en owner_id para gestión y eliminación masiva por usuario, y un GSI en deletion_marked_at para el procesamiento de recuperación. Justificación: El patrón de acceso clave-valor se mapea limpiamente a DynamoDB. El short_id es la clave única natural. El TTL está incorporado. Para otros proveedores de nube, use Cosmos DB con TTL o Scylla/Cassandra con TTL por fila. Estrategia de caché e invalidación Objetivos: lograr una redirección del percentil 95 < 10 ms a escala, minimizar la carga de la base de datos, soportar multiregión. Capas: - Caché de CDN (borde) de respuestas de redirección. El borde almacena en caché 301/302 con TTL de caché calculado a partir de la caducidad del mapeo; el TTL máximo de caché se limita a la TTL restante. Para URL cortas recién creadas, establezca una TTL de caché corta durante los primeros N segundos para permitir la consistencia. - Clúster Redis regional (ElastiCache Redis Cluster con modo clúster habilitado). Redis almacena el mapeo short_id -> respuesta de redirección serializada y metadatos de caducidad. El TTL de conjunto de Redis es igual a la caducidad del mapeo. - Caché LRU local en proceso (pequeña) en el servicio de redirección para accesos de microsegundos. Suposiciones de aciertos de caché y dimensionamiento: - Asumir una tasa de aciertos de CDN del 70% para URL cortas (enlaces populares); tasa de aciertos de Redis para fallos de borde ~85% para patrones de acceso regionales. Estos son ajustables según el uso. Población e invalidación de caché: - En escritura: el Servicio de Escritura escribe en la base de datos y escribe inmediatamente en Redis regional y publica un evento de invalidación de caché en el flujo de eventos al que todas las regiones se suscriben. Esto garantiza que las cachés estén calientes y sean consistentes en tiempo casi real. - En actualización o eliminación: el Servicio de Escritura actualiza la base de datos y publica un evento de invalidación; los suscriptores eliminan las claves de Redis y caducan las cachés de borde a través de cabeceras de control de caché o enviando PURGE/API de caché a la CDN (o estableciendo una TTL de caché corta a 0 y dejando que el borde obtenga datos frescos). Las llamadas de purga se mantienen mínimas; se prefiere la expiración basada en TTL y la invalidación pub/sub. - Para la expiración de TTL: confiar en el TTL de la base de datos para eliminar la fila y los trabajadores en segundo plano para publicar un evento de invalidación para limpiar las cachés y agregar el token a la cola de recuperación. Ruta de lectura (detallada) y cálculos de rendimiento Cálculos de tráfico (mensual base -> por segundo): - Escrituras: 100.000.000 / 30 / 24 / 3600 ~= 38,6 escrituras/segundo promedio. Factor pico de 5 asumido para tráfico diurno/picos -> ~193 escrituras/segundo pico. - Lecturas (redirecciones): 10.000.000.000 / 30 / 24 / 3600 ~= 3.858 lecturas/segundo promedio. Factor pico de 5 -> ~19.290 lecturas/segundo pico. - Relación lectura-escritura: 100:1 según lo especificado. Ruta de lectura (optimizada para latencia): 1. El cliente solicita short.example/abc1234 -> DNS resuelve al nodo de borde de la CDN. 2. Búsqueda en caché de borde: si la redirección está en caché, devuelve inmediatamente HTTP 301/302. Esto cubre la mayoría de las solicitudes de enlaces populares. 3. Si no se encuentra en el borde: la solicitud se reenvía al balanceador de carga regional -> Servicio de Redirección. 4. El Servicio de Redirección consulta la caché en proceso (diminuta) -> Redis cluster get(short_id). La obtención de Redis es de sub-milisegundos dependiendo de la red (generalmente <1 ms dentro de la región). Si se encuentra en Redis, el servicio devuelve la redirección y el borde la almacena en caché con el TTL apropiado. 5. Si no se encuentra en Redis: el servicio consulta la base de datos principal (DynamoDB GetItem) que es de un solo dígito de ms, típicamente 3-6 ms. El servicio devuelve la redirección y rellena Redis y la caché de borde. Capacidad de rendimiento y ejemplos de dimensionamiento: - Clúster Redis: asumir un pico de 20k lecturas/segundo. Desplegar 3-5 fragmentos con replicación para manejar más de 50k operaciones/segundo y proporcionar margen. Cada fragmento dimensionado para ~10k operaciones/segundo (tipo de nodo apropiado). Réplicas de lectura en cada AZ para alta disponibilidad. - DynamoDB: necesita capacidad para escrituras ~200 TPS pico y lecturas para fallos de caché. Si la tasa de aciertos de caché es del 90% en general, la carga de lectura de la base de datos = 19.290 * 0.10 ~= 1.929 lecturas/segundo en pico. Con picos eventuales y factor de seguridad 2, aprovisionar para 4k lecturas/segundo fuertemente consistentes (o usar lecturas eventualmente consistentes para reducir a la mitad el costo de RCU). Ruta de escritura (detallada) y rendimiento Ruta de escritura: 1. El cliente envía la solicitud de creación a la API -> API Gateway -> balanceador de carga regional -> Servicio de Escritura. 2. El Servicio de Escritura valida la URL (sanitización, comprobaciones de malware opcionales), comprueba los límites de tasa y las cuotas. 3. Generador de ID: utiliza CSPRNG para crear el token; intenta insertar en la base de datos con PutItem condicional de que short_id no exista (atómico). Si PutItem falla debido a una clave existente (raro), reintenta la generación. La inserción incluye long_url, created_at, expires_at. 4. Tras una inserción exitosa, el Servicio de Escritura escribe en Redis para el calentamiento inmediato de la caché y publica un evento en el flujo para análisis y propagación entre regiones. 5. Devuelve la URL corta al cliente. Dimensionamiento del rendimiento para escrituras: - Base de 39 escrituras/segundo promedio, pico aprovisionado ~200 escrituras/segundo. DynamoDB soporta fácilmente miles de escrituras/segundo con capacidad adecuada o modo bajo demanda. - Servicio de Escritura sin estado escalado horizontalmente: asumir que cada instancia puede manejar 200-500 req/s; establecer grupo de escalado automático para mantener margen. A 200 escrituras/segundo pico, 2-4 instancias son suficientes; asignar 10-20 para redundancia y otro procesamiento como limitación de tasa. Estrategia de escalado y manejo de crecimiento 10x Escenario: el crecimiento 10x significa mil millones de escrituras/mes y cien mil millones de redirecciones/mes. Estrategias: - Escalado automático: todos los servicios sin estado (Escritura/Redirección) se escalan automáticamente según la CPU/RPS y la latencia de las solicitudes. Usar escalador automático de clúster para contenedores. - Escalado de caché: agregar fragmentos de Redis y aumentar la memoria. El modo clúster de Redis permite el re-fragmentación dinámica. La CDN maneja el escalado de borde automáticamente. - Escalado de base de datos: DynamoDB admite escalado bajo demanda o aumenta la capacidad de escritura/lectura; para Cassandra/Scylla autoalojados, agregar nodos y reequilibrar tokens. - Fragmentación: la clave hash de DynamoDB ya se distribuye entre fragmentos. Para Cassandra, asegúrese de que haya suficientes nodos para mantener los fragmentos pequeños. - Limitación de tasa y contrapresión: para picos repentinos, aplique límites de tasa por usuario y por clave de API y ponga en cola tareas en segundo plano para trabajos no críticos (análisis). Implemente degradación elegante (por ejemplo, denegar nuevas creaciones para clientes abusivos) en lugar de afectar las redirecciones. - Tráfico global: agregar más regiones y replicar datos. Agregar réplicas de lectura de Redis entre regiones o confiar en el almacenamiento en caché local rellenado por lecturas bajo demanda. Estimación de capacidad después de 10x: - Picos de lectura ~200k/segundo. Con una tasa de aciertos de caché del 90%, las lecturas de la base de datos en pico ~20k/segundo. Se requerirá DynamoDB/DAX o caché administrada delante de la base de datos. El clúster Redis se escala a cientos de fragmentos, y la CDN sigue siendo la principal para reducir la carga global. Despliegue multirregión y modelo de consistencia Modelo elegido: multiregión activo-activo con consistencia eventual entre regiones para datos no críticos. Usar Tablas Globales de DynamoDB o replicación multizona de Cassandra. Razonamiento y compensaciones CAP: - Requisito: 99,9% de tiempo de actividad y recuperación ante desastres entre regiones. Priorizar la Disponibilidad y la Tolerancia a Particiones (AP) sobre la Consistencia estricta (CP) porque las redirecciones deben permanecer disponibles incluso durante particiones de región. Un ligero retraso en la replicación de URL cortas recién creadas en otra región es aceptable; el usuario que creó la URL generalmente la usa inmediatamente en la misma región y la verá debido a la escritura local y el calentamiento de la caché. - Implementación: el Servicio de Escritura escribe en la base de datos de la región local (DynamoDB local o tabla de la misma región) y luego la replicación a otras regiones ocurre a través de tablas globales. Las lecturas en una región prefieren leer localmente. Para una fuerte consistencia de lectura después de escritura local, use la lectura fuertemente consistente de DynamoDB en la misma región inmediatamente después de la escritura, o simplemente confíe en el calentamiento inmediato de la caché para garantizar que la redirección funcione en la región del escritor. Compensaciones: - La consistencia eventual simplifica la disponibilidad global y reduce la latencia de las lecturas. Permite una breve ventana en la que una URL corta creada en la región A puede no ser visible en la región B hasta que finalice la replicación. Aceptamos esto porque las principales preocupaciones del SLA son la disponibilidad y la latencia de las redirecciones. - Si se requiriera consistencia estricta entre regiones, tendríamos que implementar un modelo CP con replicación síncrona entre regiones, lo que aumentaría significativamente la latencia de escritura y reduciría la disponibilidad durante las particiones; por lo tanto, se rechazó. Expiración de TTL y mecanismo de recuperación de URL Requisitos: TTL configurable por URL corta (predeterminado 5 años), las URL caducadas deben ser recuperables. Mecanismo: - Usar el atributo TTL de la base de datos (expires_at). DynamoDB elimina automáticamente los elementos después de que pasa el TTL, pero la eliminación es eventualmente consistente y puede no ser inmediata (puede llevar hasta 48 horas en algunos sistemas). Por lo tanto, implementamos un pipeline de recuperación activo. - Cuando expires_at se acerca (por ejemplo, dentro de las 24 horas), los trabajadores en segundo plano marcan la URL como caducada y envían un evento a través del flujo. Esto permite que las cachés establezcan TTL cortas y preparen la purga. - En la expiración real, los trabajadores en segundo plano escanean las filas caducadas (usando GSI en deletion_marked_at o eventos TTL de tabla) y mueven la clave a una Cola de Recuperación con metadatos: short_id, deletion_marked_at, original_expires_at. - Política de recuperación: Introducir un período de gracia configurable (por ejemplo, 30 días) después de la expiración durante el cual el short_id se marca como 'tombstone' (bandera de eliminado y registro de 'tombstone' retenido) para evitar la reutilización inmediata y para proteger contra el retraso de replicación y las disputas de usuarios. Durante el período de 'tombstone', el short_id se resuelve a 404 o a una página de "este enlace ha caducado"; los clics se registran para auditoría. - Después del período de gracia, el trabajador de recuperación mueve el short_id a un Pool de Tokens Recuperables (tema de Kafka o tabla de pool de tokens de DynamoDB). Los tokens en el pool pueden reciclarse; los tokens recuperados incluyen un período de enfriamiento y nunca se emiten inmediatamente al mismo propietario a menos que se solicite explícitamente. - Para evitar colisiones de reutilización y abuso, mantener un índice de 'tombstone' para tokens usados recientemente (tamaño limitado, por ejemplo, retener durante 1 año en una tabla separada) y verificar antes de la reutilización. Alternativamente, en lugar de reutilizar tokens, se prefiere mantener la tasa de reciclaje extremadamente baja ya que el espacio de 7 caracteres es grande. Modos de fallo y recuperación 1) Interrupción de CDN / Edge en una región o interrupción global del proveedor de borde - Impacto: El almacenamiento en caché de borde se detiene; más solicitudes llegan a los servicios de redirección regionales y a las cachés de backend, lo que aumenta la carga y la latencia. - Recuperación: El tráfico se redirige por DNS/anycast a otros bordes o a un origen de respaldo. Escalado automático de la flota de redirección y aumento del número de instancias. Usar Origin Shield y configurar la conmutación por error del origen. Servir redirecciones directamente desde el origen hasta que el borde se recupere. 2) Fallo de la región de la base de datos principal (interrupción completa de AZ/región) - Impacto: La base de datos local no está disponible; las escrituras y lecturas no se pueden servir desde esa región. - Recuperación: Conmutación por error a otra región a través de tablas globales. Redirigir DNS y API Gateway a regiones saludables. Dado que los datos se replican asíncronamente, las escrituras recientes en la región fallida pueden perderse por un corto tiempo a menos que las escrituras se hayan replicado previamente. El sistema acepta esto a cambio de alta disponibilidad. La reconciliación en segundo plano intenta reparar conflictos una vez que la región regresa. 3) Fallo o partición del clúster Redis - Impacto: Aumentan los fallos de caché, lo que genera una mayor carga en la base de datos y una mayor latencia. - Recuperación: Los clientes recurren a lecturas de la base de datos; escalar la capacidad de lectura de la base de datos o habilitar DAX (DynamoDB Accelerator) o nodos Redis adicionales. Reconstruir el clúster Redis a partir de instantáneas de la base de datos o calentar las cachés mediante la pre-carga de las claves más activas utilizando análisis/listas de claves activas. Usar Redis Sentinel o clúster Redis administrado con conmutación por error automática para garantizar la redundancia a nivel de nodo. 4) Error del servicio generador de ID que causa colisiones o agotamiento del límite de tasa - Impacto: Fallos de escritura, errores de token duplicado o incapacidad para crear nuevos tokens. - Recuperación: Diseñar el generador como CSPRNG sin estado; si se detecta un error, revertir a una versión estable anterior y dirigir las solicitudes a una implementación de generador de respaldo (por ejemplo, una biblioteca RNG diferente o un contador de respaldo de corta duración combinado con una sal HMAC). Agregar monitorización de la tasa de colisión; si la tasa de colisión > umbral trivial, dejar de emitir nuevos tokens y devolver 5xx hasta que se solucione. 5) Retraso en la cola del consumidor del flujo de eventos o fallo del trabajador - Impacto: Se retrasan las invalidaciones de caché, el procesamiento de análisis y la recuperación. - Recuperación: Escalar automáticamente los consumidores, priorizar los temas de invalidación y recuperación, y establecer la retención para que los nuevos consumidores puedan ponerse al día. Reconstruir el estado desde la base de datos si es necesario. Compensaciones clave y alternativas consideradas 1) Elección de almacenamiento: DynamoDB (NoSQL administrado) vs. RDBMS vs. Cassandra/Scylla - Elegido: DynamoDB (o Cassandra administrado). Razón: escala horizontal, TTL, servicio administrado, tablas globales para multiregión. RDBMS rechazado debido a la complejidad de escalado, fragmentación y latencia de fila única más lenta a escala extrema. 2) Generación de tokens: Token aleatorio vs. contador secuencial vs. hash de URL larga - Elegido: Tokens aleatorios criptográficamente seguros mapeados a base62 de 7 caracteres. Razón: no adivinable, distribución uniforme, escalado trivial, pequeña probabilidad de colisión resuelta por inserción condicional en la base de datos. Contadores secuenciales rechazados porque son adivinables. Hash determinista rechazado debido a mayor riesgo de colisión y previsibilidad. 3) Multiregión activo-activo vs. conmutación por error activo-pasivo - Elegido: Activo-activo con consistencia eventual. Razón: mejor disponibilidad y enrutamiento de clientes más simple a la región más cercana con baja latencia. Activo-pasivo proporciona una consistencia más fuerte pero aumenta el tiempo de conmutación por error y podría violar los requisitos de latencia/disponibilidad. 4) Recuperación de tokens vs. nunca reutilizar tokens - Elegido: Recuperable con período de gracia/tombstone. Razón: el espacio de tokens es grande, por lo que la reutilización no es necesaria a menudo, pero la recuperación es requerida por la especificación. La seguridad aumenta con la retención de tombstone y el enfriamiento antes de la reemisión. Nunca reutilizar rechazado porque después de muchos años podría haber necesidad de conservar el espacio de nombres si los tokens se agotan en escenarios patológicos. 5) Almacenamiento en caché en el borde vs. solo origen directo - Elegido: Almacenamiento en caché intensivo en el borde con TTL cortas. Razón: cumplir con la latencia del percentil 95 < 10 ms para usuarios globales. Solo origen directo rechazado porque la latencia del origen y los saltos entre regiones excederían el SLA de latencia. Consideraciones operativas y números - SLO: 99,9% de tiempo de actividad; monitorizar la salud y la latencia en el borde, redis, base de datos y servicio de escritura. Establecer umbrales de alerta para tasas de error y latencia del percentil 95. - Ejemplos de planificación de capacidad: para tráfico base, aprovisionar la base de datos para ~4k lecturas/segundo y ~200 escrituras/segundo pico; clúster Redis dimensionado para ~30k operaciones/segundo. Para escala 10x, aprovisionar la base de datos para ~40k lecturas/segundo y Redis para ~300k operaciones/segundo con fragmentos de escalado automático. - Mitigación de seguridad y abuso: limitación de tasa por clave de API/IP, escaneo de URL en busca de malware (asíncrono opcional), aplicación de cuotas por cuenta. - Retención de datos y privacidad: proporcionar APIs de gestión para que los usuarios eliminen/extiendan TTL; semántica de eliminación suave para auditabilidad y retención de tombstone. Resumen Este diseño utiliza un enfoque de almacenamiento en caché en varias capas (borde de CDN + Redis regional) respaldado por un almacén NoSQL escalable horizontalmente (DynamoDB o Cassandra) y microservicios sin estado para cumplir con los requisitos de rendimiento y latencia. La generación de tokens utiliza tokens base62 de 7 caracteres basados en CSPRNG con resolución de colisiones respaldada por la base de datos para garantizar que no sean adivinables. El sistema favorece la disponibilidad y la tolerancia a particiones (consistencia eventual multiregión activo-activo) para cumplir con los SLA de tiempo de actividad y latencia, mientras que la recuperación y el TTL se manejan mediante el TTL de la base de datos más un pipeline de recuperación con una ventana de gracia de tombstone para evitar la reutilización accidental. La arquitectura escala horizontalmente con escalado automático y fragmentación para acomodar un crecimiento 10x, e incluye rutas de recuperación para modos de fallo comunes para cumplir el objetivo de tiempo de actividad del 99,9%.

Este diseño de sistema describe un servicio de acortamiento de URL robusto, escalable y altamente disponible, capaz de manejar 100 millones de acortamientos nuevos y 10 mil millones de redirecciones por mes, con estrictos requisitos de latencia y tiempo de actividad. Descripción general de la arquitectura: La arquitectura está diseñada para alta disponibilidad, escalabilidad y baja latencia, aprovechando un enfoque de microservicios. Los componentes clave incluyen: 1. **Balanceadores de Carga (por ejemplo, AWS ELB/GCP Load Balancer/Nginx)**: Distribuyen el tráfico entrante entre las instancias del servicio. 2. **API Gateway (por ejemplo, AWS API Gateway/Kong)**: Maneja las solicitudes de API, la autenticación, la limitación de velocidad y enruta el tráfico a los servicios backend apropiados. 3. **Servicio de Acortamiento (Ruta de Escritura)**: Un microservicio sin estado responsable de procesar las solicitudes para crear nuevas URL cortas. Interactúa con el Servicio de Generación de Claves y la Base de Datos. 4. **Servicio de Redirección (Ruta de Lectura)**: Un microservicio sin estado altamente optimizado responsable de resolver URL cortas a URL largas y realizar la redirección HTTP 301/302. Depende en gran medida del almacenamiento en caché. 5. **Servicio de Generación de Claves**: Un servicio dedicado responsable de pregenerar y administrar un grupo de claves de URL cortas únicas y aleatorias. Garantiza que no sean predecibles y evita colisiones. 6. **Base de Datos (por ejemplo, Apache Cassandra)**: El almacenamiento persistente principal para las asignaciones de URL cortas. Elegido por su alto rendimiento de escritura/lectura, escalabilidad horizontal y capacidades de replicación multirregión. 7. **Caché Distribuida (por ejemplo, Redis Cluster)**: Almacena las asignaciones de URL cortas accedidas con frecuencia para reducir la carga de la base de datos y lograr una baja latencia de redirección. 8. **Cola de Mensajes (por ejemplo, Apache Kafka/AWS SQS)**: Se utiliza para la comunicación asíncrona entre servicios, como la publicación de eventos para análisis, invalidación de caché y expiración de URL. 9. **Servicio de Análisis**: Consume eventos de la cola de mensajes para rastrear recuentos de clics, generar informes y monitorear patrones de uso. 10. **Servicio de Expiración y Recuperación**: Un servicio de trabajador en segundo plano responsable de identificar URL expiradas, marcarlas y devolver sus claves al grupo del Servicio de Generación de Claves para su reutilización. 11. **CDN (Red de Entrega de Contenido, por ejemplo, Cloudflare/Akamai)**: Opcional pero muy recomendable para almacenar en caché las redirecciones en el borde, reduciendo aún más la latencia y la carga del servidor de origen para usuarios globales. Interacciones: * **Ruta de Escritura**: Usuario -> Balanceador de Carga -> API Gateway -> Servicio de Acortamiento -> Servicio de Generación de Claves (obtiene clave) -> Base de Datos (escribe asignación) -> Cola de Mensajes (publica evento 'new_url') -> Caché (actualiza/escribe a través). * **Ruta de Lectura**: Usuario -> Balanceador de Carga -> CDN (si hay acierto, redirige) -> Servicio de Redirección (verifica caché local -> caché distribuida -> base de datos) -> Redirección. Algoritmo de acortamiento de URL y estrategia de generación de claves: Para garantizar que no sean predecibles, sean únicas y cumplan con el límite de 7 caracteres, se emplea una estrategia de pregeneración: 1. **Servicio de Generación de Claves**: Este servicio genera continuamente cadenas alfanuméricas aleatorias de 7 caracteres (por ejemplo, utilizando un generador de números pseudoaleatorios criptográficamente seguro). El conjunto de caracteres incluye `a-z`, `A-Z`, `0-9`, totalizando 62 caracteres. Una cadena de 7 caracteres permite 62^7 claves únicas, que son aproximadamente 3.5 billones, superando con creces el requisito de 100 millones de URL/mes. 2. **Verificación de Unicidad**: Antes de agregar al grupo, cada clave generada se verifica en busca de unicidad contra la base de datos (o una tienda de claves únicas dedicada). Esta es una verificación única durante la generación, no durante las solicitudes de acortamiento. 3. **Grupo de Claves**: Las claves únicas se almacenan en un grupo de acceso rápido y alta disponibilidad (por ejemplo, un conjunto de Redis o una tabla dedicada en Cassandra con un campo 'estado' como 'disponible'). El Servicio de Generación de Claves mantiene un gran búfer (por ejemplo, varios miles de millones de claves) para garantizar que las claves estén siempre fácilmente disponibles. 4. **Proceso de Acortamiento**: Cuando un usuario solicita una nueva URL corta, el Servicio de Acortamiento solicita una clave al Servicio de Generación de Claves. El Servicio de Generación de Claves extrae atómicamente una clave disponible de su grupo, la marca como 'en uso' y la devuelve. Esto evita la contención durante cargas de escritura elevadas. 5. **Evitación de Colisiones**: Al pregenerar y asignar atómicamente claves únicas, las colisiones durante la solicitud de acortamiento real se eliminan virtualmente. La base de datos también aplica una restricción única en la `short_url_key` como salvaguarda final. Esquema de la base de datos y elección de la tecnología de almacenamiento: Elección de la base de datos: **Apache Cassandra** (o AWS DynamoDB como alternativa administrada). Justificación: * **Alto rendimiento de escritura/lectura**: Cassandra está diseñada para operaciones de alto volumen y baja latencia, perfecta para la relación de lectura/escritura de 100:1 y miles de millones de lecturas. * **Escalabilidad Horizontal**: Se escala fácilmente agregando más nodos, distribuyendo datos y carga en todo el clúster. * **Alta Disponibilidad y Tolerancia a Fallos**: Los datos se replican en múltiples nodos y centros de datos, garantizando una operación continua incluso durante fallos de nodos. * **Consistencia Eventual**: Aceptable para este caso de uso. Si bien una nueva URL puede tardar milisegundos en propagarse entre regiones, no afecta la funcionalidad principal. * **Búsquedas simples de clave-valor**: El patrón de acceso principal es `short_url_key` a `long_url`, en lo que Cassandra sobresale. Esquema (Keyspace: `url_shortener`, Tabla: `short_urls`): ``` CREATE TABLE url_shortener.short_urls ( short_url_key text PRIMARY KEY, -- Clave de partición, 7 caracteres alfanuméricos long_url text, user_id text, -- Opcional, para URL específicas del usuario created_at timestamp, expires_at timestamp, click_count counter, -- Tipo contador de Cassandra para incrementos atómicos status text -- 'active', 'expired', 'reclaimed' ); ``` Estrategia de caché e enfoque de invalidación de caché: El almacenamiento en caché es fundamental para lograr la latencia de redirección <10 ms y manejar 10 mil millones de redirecciones/mes. Estrategia: 1. **Caché multinivel**: * **CDN (Caché de borde)**: Almacena en caché las redirecciones en puntos de presencia distribuidos geográficamente. Esta es la primera línea de defensa para las solicitudes de lectura. * **Caché Distribuida (Redis Cluster)**: Una caché central de alto rendimiento que almacena asignaciones de `short_url_key` a `long_url`. Cada entrada también almacena `expires_at`. * **Caché en memoria**: Cada instancia del Servicio de Redirección mantiene una pequeña y rápida caché en memoria para las URL más populares. 2. **Lectura a través (Read-Through)**: Cuando el Servicio de Redirección recibe una solicitud, primero verifica su caché en memoria, luego el Clúster de Redis. Si no se encuentra, recupera de Cassandra, almacena la asignación en Redis y su caché local, y luego redirige. 3. **Escritura a través (Write-Through)**: Cuando se acorta una nueva URL, el Servicio de Acortamiento escribe la asignación en Cassandra y luego la escribe inmediatamente en el Clúster de Redis. Invalidación de caché: 1. **Expiración basada en TTL**: Las entradas de caché en Redis y las cachés en memoria tienen un TTL configurable (por ejemplo, 5 minutos o alineado con `expires_at` de la URL). Esto maneja la consistencia eventual y garantiza que los datos obsoletos no persistan indefinidamente. 2. **Invalidación explícita**: Cuando una URL expira o es recuperada por el Servicio de Expiración y Recuperación, se publica un evento en la Cola de Mensajes. Los trabajadores de invalidación de caché consumen este evento y eliminan explícitamente la entrada correspondiente del Clúster de Redis. Las cachés de CDN se invalidan a través de llamadas a la API o estableciendo encabezados `Cache-Control` apropiados con un `max-age` corto para las redirecciones. Ruta de lectura y ruta de escritura con cálculos de rendimiento: Supuestos: 1 mes = 2,592,000 segundos. Ruta de escritura (100 millones de acortamientos de URL nuevos por mes): * **Rendimiento promedio**: 100,000,000 URL / 2,592,000 segundos ≈ 38.6 escrituras/segundo. * **Rendimiento pico**: Suponiendo que el pico sea 3 veces el promedio, diseñar para ~120 escrituras/segundo. * **Flujo**: Balanceador de Carga -> API Gateway -> Servicio de Acortamiento (solicita clave al Servicio de Generación de Claves, escribe en Cassandra, escribe en Redis, publica evento en Kafka). * **Componentes**: Múltiples instancias de Servicio de Acortamiento, Servicio de Generación de Claves, nodos de Cassandra, nodos de Redis, brokers de Kafka. * **Objetivo de latencia**: Menos de 100 ms para escrituras (menos crítico que las lecturas). Ruta de lectura (10 mil millones de redirecciones por mes): * **Rendimiento promedio**: 10,000,000,000 redirecciones / 2,592,000 segundos ≈ 3,858 lecturas/segundo. * **Rendimiento pico**: Suponiendo que el pico sea 3 veces el promedio, diseñar para ~12,000 lecturas/segundo. * **Flujo**: Usuario -> CDN (si hay acierto, redirige) -> Balanceador de Carga -> Servicio de Redirección (verifica caché en memoria -> Clúster de Redis -> Cassandra) -> Redirección. * **Relación de aciertos de caché**: Apuntar a una relación de aciertos de caché >95% (CDN + Redis) para descargar Cassandra. * **Lecturas efectivas de DB**: 12,000 lecturas/seg * 5% (fallo de caché) = 600 lecturas/segundo a Cassandra. * **Objetivo de latencia**: Menos de 10 ms en el percentil 95. * **Componentes**: Numerosas instancias de Servicio de Redirección, nodos de Clúster de Redis, nodos de Cassandra. La CDN juega un papel crucial. Estrategia de escalado: 1. **Escalado Horizontal (Servicios sin estado)**: Todos los servicios sin estado (API Gateway, Servicio de Acortamiento, Servicio de Redirección, Servicio de Generación de Claves, Servicio de Análisis, Servicio de Expiración y Recuperación) se implementan como múltiples instancias detrás de balanceadores de carga. Se pueden escalar agregando más instancias según la utilización de la CPU, la memoria o la profundidad de la cola de solicitudes (por ejemplo, utilizando HPA de Kubernetes o Grupos de Escalado Automático de AWS). 2. **Escalado de Base de Datos (Cassandra)**: Cassandra escala horizontalmente agregando más nodos al clúster. Los datos se reequilibran automáticamente. Esto permite aumentar la capacidad de almacenamiento y el rendimiento de lectura/escritura. 3. **Escalado de Caché (Redis Cluster)**: Redis Cluster proporciona fragmentación y replicación, lo que permite escalar horizontalmente agregando más nodos maestros y réplicas. 4. **Escalado de Cola de Mensajes (Kafka)**: Kafka es inherentemente escalable, lo que permite aumentar el rendimiento agregando más brokers y particiones. 5. **CDN**: Descarga una porción significativa del tráfico de lectura de los servidores de origen, escalando efectivamente la ruta de lectura a nivel mundial. 6. **Microservicios**: La arquitectura modular permite escalar servicios individuales de forma independiente según sus requisitos de carga específicos. Despliegue multirregión y modelo de consistencia de datos: Para lograr un tiempo de actividad del 99.9% y recuperación ante desastres, el servicio se implementará en una configuración Activa-Activa en al menos dos regiones geográficas (por ejemplo, US-East y EU-West). Despliegue: * Cada región aloja una pila completa e independiente de todos los servicios (Balanceadores de Carga, API Gateway, Servicios de Acortamiento/Redirección, Servicio de Generación de Claves, clúster de Cassandra, Clúster de Redis, clúster de Kafka, etc.). * Un Balanceador de Carga Global (por ejemplo, AWS Route 53 con enrutamiento basado en latencia o un administrador de tráfico global) dirige a los usuarios a la región saludable más cercana. Modelo de consistencia de datos: * **Replicación de Cassandra Multicentro de Datos**: Se utiliza la `NetworkTopologyStrategy` de Cassandra para replicar datos de forma asíncrona entre los clústeres regionales. Cada región mantiene una copia completa de los datos. * **Escrituras**: Las escrituras se realizan típicamente con consistencia `LOCAL_QUORUM` dentro de la región principal para una baja latencia. La replicación integrada de Cassandra garantiza la consistencia eventual entre regiones. Una nueva URL corta creada en la Región A eventualmente se propagará a la Región B. * **Lecturas**: Las lecturas también se realizan típicamente con consistencia `LOCAL_QUORUM` para baja latencia, sirviendo datos del clúster de Cassandra o caché de la región local. Si una clave no se encuentra localmente (por ejemplo, debido al retraso de replicación de una URL muy nueva), se podría implementar un respaldo a una lectura entre regiones, pero esto incurriría en una mayor latencia. Dada la naturaleza de lectura intensiva y la caché, esto es raro. Compromisos (Teorema CAP): * **Elegido**: Priorizar la **Disponibilidad** y la **Tolerancia a Particiones** sobre la **Consistencia** fuerte entre regiones. * **Razonamiento**: Para un servicio de acortamiento de URL, es más crítico que el servicio esté siempre disponible y funcione rápidamente, incluso si una URL recién creada tarda unos milisegundos en ser accesible a nivel mundial. La consistencia fuerte entre centros de datos geográficamente dispersos introduciría una latencia de escritura y una complejidad inaceptables. La consistencia eventual es un compromiso adecuado. Mecanismo de expiración TTL y recuperación de URL: 1. **Expiración**: Se utiliza la marca de tiempo `expires_at` en la tabla `short_urls`. El Servicio de Expiración y Recuperación (un conjunto de trabajadores en segundo plano) escanea periódicamente la tabla `short_urls` en busca de entradas donde `expires_at` esté en el pasado y el `status` sea 'active'. * Al identificar una URL expirada, el servicio actualiza su `status` a 'expired' en Cassandra. * Luego publica un evento 'url_expired' en la Cola de Mensajes, activando la invalidación de caché para esa `short_url_key` en Redis y CDN. 2. **Recuperación**: Después de un período de gracia configurable (por ejemplo, 24-48 horas) posterior a la expiración (para garantizar que todas las cachés se limpien y no se vean afectadas las redirecciones en curso), el Servicio de Expiración y Recuperación identifica las URL con `status` 'expired' que están más allá de su período de gracia. * Luego actualiza su `status` a 'reclaimable'. * La `short_url_key` se agrega de nuevo al grupo de claves disponibles del Servicio de Generación de Claves. Esto garantiza que el espacio de claves alfanuméricas de 7 caracteres se reutilice de manera eficiente con el tiempo. * Se puede realizar una verificación final de unicidad antes de volver a agregar al grupo, aunque el diseño del Servicio de Generación de Claves debería evitar colisiones reales. Modos de fallo y recuperación: 1. **Fallo de nodo de base de datos (por ejemplo, caída de nodo de Cassandra)**: * **Detección**: Los sistemas de monitoreo detectan la inalcanzabilidad del nodo o altas tasas de error. * **Recuperación**: La arquitectura distribuida de Cassandra con un factor de replicación (RF) de 3 (o superior) garantiza la redundancia de datos. Si falla un nodo, otras réplicas sirven los datos. El clúster permanece operativo. El nodo fallido puede ser reemplazado automáticamente o puesto en línea manualmente. Sin pérdida de datos, interrupción mínima del servicio. 2. **Fallo del Servicio de Generación de Claves**: * **Detección**: Las comprobaciones de estado y el monitoreo detectan la indisponibilidad del servicio o el agotamiento del grupo de claves. * **Recuperación**: El Servicio de Generación de Claves se implementa con múltiples instancias. Si una falla, otras toman el control. Si falla todo el servicio, las solicitudes de acortamiento de URL nuevas fallarán temporalmente ya que no pueden obtener una clave única. Sin embargo, las redirecciones existentes continuarán funcionando normalmente. Los grupos de escalado automático lanzarán nuevas instancias. Un gran búfer de claves pregeneradas (miles de millones de claves) reduce significativamente el impacto de las interrupciones temporales. 3. **Fallo del Clúster de Caché (por ejemplo, interrupción de Redis Cluster)**: * **Detección**: El monitoreo detecta la inalcancialidad del nodo o clúster de Redis. * **Recuperación**: El Servicio de Redirección está diseñado para recurrir a la base de datos Cassandra si la caché no está disponible. Esto provocará un aumento de la latencia de redirección (de <10 ms a potencialmente 50-100 ms) y una mayor carga en Cassandra, pero el servicio permanecerá completamente funcional (rendimiento degradado). Redis Cluster con replicación proporciona alta disponibilidad, mitigando fallos completos del clúster. 4. **Fallo de Región Completa**: * **Detección**: El Balanceador de Carga Global (por ejemplo, comprobaciones de estado de Route 53) detecta que todos los servicios en una región no están saludables. * **Recuperación**: El Balanceador de Carga Global dirige automáticamente todo el tráfico a la región secundaria saludable. Los usuarios pueden experimentar un breve pico de latencia durante la conmutación por error, pero el servicio permanece disponible. La consistencia de los datos puede estar ligeramente desfasada, pero el sistema está diseñado para tolerar la consistencia eventual. Compromisos clave realizados y alternativas consideradas: 1. **Consistencia vs. Disponibilidad/Latencia (Teorema CAP)**: * **Elegido**: Consistencia eventual para la replicación de datos entre regiones y alta disponibilidad/lecturas de baja latencia. * **Rechazado**: Consistencia fuerte entre regiones. * **Razonamiento**: La consistencia fuerte introduciría una latencia significativa para las escrituras y las lecturas entre regiones, lo cual es inaceptable para un servicio de redirección de alto rendimiento y baja latencia. Unos pocos milisegundos de inconsistencia para una nueva asignación de URL son un compromiso menor en comparación con los beneficios de alta disponibilidad y rendimiento. 2. **Estrategia de Generación de Claves (Pregeneradas vs. Hash/Secuencial sobre la marcha)**: * **Elegido**: Claves alfanuméricas aleatorias pregeneradas a través de un servicio dedicado. * **Rechazado**: Hash de la URL larga (por ejemplo, MD5, SHA-256 truncado) o uso de un codificador base-62 en un ID de auto-incremento. * **Razonamiento**: El hash puede generar colisiones (especialmente con un límite de 7 caracteres) que requieren una lógica compleja de resolución de colisiones, agregando latencia y complejidad a la ruta de escritura. Base-62 en IDs de auto-incremento hace que las URL sean secuenciales y predecibles, violando un requisito clave. La pregeneración garantiza la unicidad, la imprevisibilidad y la recuperación rápida de claves durante las escrituras, simplificando el proceso de acortamiento. 3. **Elección de Base de Datos (NoSQL vs. SQL Relacional)**: * **Elegido**: Apache Cassandra (NoSQL). * **Rechazado**: PostgreSQL/MySQL (SQL Relacional). * **Razonamiento**: Las bases de datos relacionales tienen dificultades con el rendimiento extremo de lectura/escritura y los requisitos de escalabilidad horizontal de este servicio sin una complejidad de fragmentación significativa. Las bases de datos NoSQL como Cassandra están diseñadas específicamente para esta escala, alta disponibilidad y rendimiento, especialmente para búsquedas simples de clave-valor, que es el patrón de acceso principal. 4. **Implementación de TTL (Servicio en segundo plano vs. TTL de base de datos)**: * **Elegido**: Servicio dedicado de Expiración y Recuperación escaneando `expires_at`. * **Rechazado**: Confiar únicamente en el TTL a nivel de base de datos (por ejemplo, TTL integrado de Cassandra). * **Razonamiento**: Si bien el TTL de la base de datos puede expirar datos automáticamente, no facilita fácilmente la recuperación controlada de la `short_url_key` de nuevo a un grupo reutilizable ni activa la invalidación explícita de la caché. Un servicio dedicado proporciona un control más granular sobre todo el ciclo de vida, incluido el período de gracia y la reutilización segura de claves.