Diseñar un servicio global de acortamiento de URL

Diseño: Servicio Global de Acortamiento de URL 1. REQUISITOS Y ESTIMACIONES PRELIMINARES Requisitos funcionales: - Crear un enlace corto para una URL larga dada (con alias personalizado opcional). - Redirigir a los visitantes del enlace corto a la URL original (HTTP 301/302). - Analíticas básicas: clics totales por enlace, clics por día durante los últimos 30 días. Requisitos no funcionales: - 120 millones de enlaces nuevos por mes, aproximadamente 46 escrituras por segundo en promedio, pico de alrededor de 200 por segundo. - 1.200 millones de redirecciones por mes, aproximadamente 463 por segundo en promedio, pico de entre 5.000 y 50.000 por segundo para enlaces virales. - 99,99% de disponibilidad de redirección. - Redirecciones globales de baja latencia. - Enlaces válidos durante al menos 5 años. - Analíticas eventualmente consistentes en un plazo de 10 minutos. - Prevención básica de abusos. Estimación de almacenamiento: - 120 millones de enlaces por mes por 60 meses (5 años) son 7.200 millones de enlaces. - Cada registro de enlace de aproximadamente 500 bytes (código corto, URL larga, metadatos) da como resultado unos 3,6 TB de datos de enlaces durante 5 años. - Los datos de analíticas son adicionales pero manejables con agregación. 2. ARQUITECTURA DE ALTO NIVEL El sistema se compone de los siguientes componentes principales: a) Pasarela API y Balanceador de Carga: Punto de entrada para todo el tráfico. Maneja la terminación TLS, limitación de velocidad, autenticación para la creación de enlaces y enrutamiento. Desplegado en múltiples regiones detrás de un DNS global anycast o un balanceador de carga global (por ejemplo, AWS Global Accelerator o Cloudflare). b) Servicio de Creación de Enlaces: Servicio sin estado que maneja las solicitudes POST para crear nuevos enlaces cortos. Valida la entrada, genera o reserva códigos cortos, verifica la disponibilidad del alias personalizado, aplica comprobaciones básicas de abuso y escribe en la base de datos principal. c) Servicio de Redirección: Servicio sin estado, optimizado para lectura, que maneja las solicitudes GET de códigos cortos. Busca primero el código corto en la caché, luego en la base de datos, y devuelve una redirección HTTP 301 o 302. También emite un evento de clic de forma asíncrona para analíticas. d) Servicio de Analíticas: Consume eventos de clics de una cola de mensajes, los agrega y almacena recuentos diarios y totales. Sirve consultas de analíticas. e) Capa de Caché: Caché distribuida (clústeres de Redis o Memcached) desplegada en cada región para servir códigos cortos populares con latencia sub-milisegundo. f) Base de Datos Principal: Almacena las correspondencias de enlaces canónicas. Una base de datos distribuida como Amazon DynamoDB, Google Cloud Spanner o CockroachDB. g) Cola de Mensajes: Kafka o Amazon Kinesis para almacenar en búfer eventos de clics entre el servicio de redirección y el pipeline de analíticas. h) CDN / Capa de Borde: Para los enlaces más populares, las respuestas de redirección se pueden almacenar en caché en el borde de la CDN (usando 301 con encabezados de caché apropiados o trabajadores de borde que realicen la búsqueda). Flujo de la arquitectura: - Creación de enlace: Cliente -> Pasarela API -> Servicio de Creación de Enlaces -> BD Principal (escritura) -> Invalidar/poblar caché -> Devolver URL corta. - Redirección: Cliente -> CDN/Borde -> (fallo de caché) -> Pasarela API -> Servicio de Redirección -> Caché -> (fallo de caché) -> BD -> Devolver redirección 302. Emitir evento de clic de forma asíncrona a la cola de mensajes. - Consulta de analíticas: Cliente -> Pasarela API -> Servicio de Analíticas -> BD de Analíticas -> Devolver resultados. 3. MODELO DE DATOS Y ALMACENAMIENTO Tabla de Mapeo de Enlaces (Almacén Principal - DynamoDB o similar): - short_code (clave de partición): cadena, 7 caracteres, por ejemplo, "aB3x9Kz" - long_url: cadena, la URL original, hasta 2048 caracteres - user_id: cadena, opcional, el creador - custom_alias: booleano, si este fue un alias personalizado - created_at: marca de tiempo - expires_at: marca de tiempo (created_at + 5 años por defecto) - click_count: entero (contador eventualmente consistente, actualizado periódicamente) - status: enum (activo, deshabilitado, expirado) Por qué DynamoDB: El patrón de búsqueda de clave-valor única es perfecto. Escala horizontalmente con latencia consistente de un solo dígito en milisegundos. La clave de partición es el short_code, que se distribuye bien dada la naturaleza aleatoria de los códigos generados. Almacén de Analíticas: - Opción A: Una tabla de series temporales en DynamoDB o Cassandra con clave de partición = short_code y clave de ordenación = fecha (AAAA-MM-DD), con un atributo click_count. - Opción B: Recuentos diarios preagregados almacenados en una tabla separada, con un TTL de 30 días para las filas de granularidad diaria. Esquema para la tabla de analíticas diarias: - short_code (clave de partición): cadena - date (clave de ordenación): cadena, formato AAAA-MM-DD - click_count: entero - TTL: marca de tiempo, 30 días a partir de la fecha Esto permite consultas de rango eficientes: obtener todos los recuentos diarios para un short_code en los últimos 30 días. Para los recuentos totales de clics, mantenemos un contador acumulado en la tabla principal de mapeo de enlaces, actualizado por el pipeline de analíticas. 4. ESTRATEGIA DE GENERACIÓN DE ID / TOKEN Requisitos: 7.200 millones de códigos únicos durante 5 años. Usando codificación base62 (a-z, A-Z, 0-9), un código de 7 caracteres da 62^7 = 3,5 billones de combinaciones posibles, lo cual es más que suficiente. Enfoque: Rangos de ID pregenerados usando un contador distribuido o asignación basada en rangos. Estrategia principal: - Usar un servicio central de generación de ID (como Twitter Snowflake o un servicio de contador más simple) que asigna rangos de ID numéricos a cada instancia del Servicio de Creación de Enlaces. Por ejemplo, cada instancia solicita un bloque de 10.000 ID a la vez. - Cada ID numérico se codifica luego a base62 para producir el código corto de 7 caracteres. - Esto evita la coordinación en cada escritura mientras asegura la unicidad global. Alternativa considerada: Generación aleatoria con comprobación de colisiones. Esto funciona pero requiere una lectura antes de escribir para comprobar colisiones, lo que añade latencia. Con 7.200 millones de códigos de 3,5 billones posibles, la probabilidad de colisión es baja (alrededor del 0,2%), pero aún así requiere la comprobación. El enfoque basado en rangos es más determinista. Gestión de alias personalizados: - Cuando un usuario solicita un alias personalizado, el servicio realiza una escritura condicional (PutItem con la condición de que el short_code no exista ya) en la base de datos. - Si la condición falla, el alias está ocupado y devolvemos un error al usuario. - Los alias personalizados se validan: mínimo 4 caracteres, máximo 30 caracteres, alfanuméricos más guiones, comprobados contra una lista de bloqueo de palabras reservadas y ofensivas. - Los alias personalizados se almacenan en la misma tabla que los códigos generados, con el indicador custom_alias establecido en verdadero. 5. DISEÑO DE API Todas las API son RESTful sobre HTTPS. a) Crear Enlace Corto: POST /api/v1/links Encabezados: Authorization: Bearer <token> (opcional para anónimo, requerido para acceso a analíticas) Cuerpo de la solicitud: long_url: requerido, la URL de destino (validada en formato y seguridad básica) custom_alias: opcional, código corto deseado expires_in_days: opcional, por defecto 1825 (5 años) Respuesta (201 Created): short_code: "aB3x9Kz" short_url: "https://sho.rt/aB3x9Kz" long_url: "https://example.com/very/long/path" created_at: "2025-01-15T10:30:00Z" expires_at: "2030-01-15T10:30:00Z" Respuestas de error: 400 (URL inválida), 409 (alias personalizado ocupado), 429 (limitado por velocidad) b) Redireccionar: GET /{short_code} Respuesta: 302 Found con encabezado Location establecido en la URL larga. Usamos 302 (redirección temporal) en lugar de 301 (redirección permanente) para que los navegadores no almacenen en caché la redirección permanentemente, lo que nos permite rastrear clics y potencialmente actualizar el destino. Sin embargo, para el rendimiento, podemos usar 301 en el borde de la CDN con un TTL apropiado. Respuestas de error: 404 (no encontrado o expirado), 410 (deshabilitado) c) Obtener Analíticas: GET /api/v1/links/{short_code}/analytics Encabezados: Authorization: Bearer <token> Respuesta (200 OK): short_code: "aB3x9Kz" total_clicks: 154302 daily_clicks: lista de objetos con fecha y recuento para los últimos 30 días Respuestas de error: 401 (no autorizado), 404 (enlace no encontrado) d) Eliminar / Deshabilitar Enlace: DELETE /api/v1/links/{short_code} Encabezados: Authorization: Bearer <token> Respuesta: 204 No Content 6. ESTRATEGIA DE CACHÉ, PARTICIONAMIENTO Y REPLICACIÓN Caché: - Capa 1 - Caché de Borde de CDN: Para la ruta de redirección, podemos almacenar en caché las respuestas 302 en el borde de la CDN con un TTL corto (por ejemplo, 5 minutos). Esto maneja enlaces virales extremadamente bien, ya que la CDN absorbe la mayoría del tráfico. Usamos encabezados Cache-Control con un max-age corto. Los trabajadores de borde (Cloudflare Workers, Lambda@Edge) también pueden realizar la búsqueda directamente desde una caché regional. - Capa 2 - Clúster de Redis Regional: Cada región tiene un clúster de Redis que almacena en caché las correspondencias de short_code a long_url. TTL de caché de 24 horas. Política de desalojo LRU. - Capa 3 - Caché local a nivel de aplicación: Cada instancia del servicio de redirección mantiene una pequeña caché LRU en memoria (por ejemplo, 100K entradas) para los enlaces más populares. Dimensionamiento de la caché: Con 1.200 millones de redirecciones por mes y una distribución de Zipf, el 20% superior de los enlaces probablemente representa el 80% del tráfico. Almacenar en caché los 10 millones de enlaces activos principales en Redis requiere aproximadamente 10 millones por 300 bytes = 3 GB por región, lo cual es muy manejable. Invalidación de caché: Al eliminar o actualizar un enlace, publicamos un evento de invalidación a todas las regiones a través de la cola de mensajes. Las entradas de caché también tienen TTL como red de seguridad. Particionamiento: - DynamoDB particiona automáticamente por la clave hash short_code. La naturaleza aleatoria de los códigos generados asegura una distribución uniforme. - Para alias personalizados, la distribución es menos predecible, pero la capacidad adaptativa de DynamoDB maneja particiones calientes. - Redis se particiona usando hashing consistente entre los nodos del clúster. Replicación: - DynamoDB Global Tables proporciona replicación multirregión con consistencia eventual (típicamente sub-segundo). Designamos una región como principal para escrituras (creación de enlaces) y todas las regiones pueden servir lecturas. - Alternativamente, con CockroachDB o Spanner, obtenemos lecturas multirregión fuertemente consistentes, pero a un costo de latencia mayor para las escrituras. - Los clústeres de Redis se replican dentro de cada región (primario-réplica). La caché entre regiones se popula de forma independiente a través de la replicación de la base de datos y el calentamiento de la caché local. 7. ENFOQUE DE FIABILIDAD Objetivo de disponibilidad: 99,99% para redirecciones significa como máximo 4,3 minutos de inactividad por mes. Despliegue multirregión: - Desplegar el servicio de redirección en al menos 3 regiones geográficamente distribuidas (por ejemplo, US-East, EU-West, AP-Southeast). - Usar enrutamiento global basado en DNS (enrutamiento basado en latencia de Route 53 o anycast) para dirigir a los usuarios a la región más cercana. - Cada región es capaz de servir redirecciones de forma independiente desde su caché local y réplica de base de datos. Gestión de fallos: - Si falla la región principal de la base de datos, se promueve otra región. Con DynamoDB Global Tables, cualquier región puede aceptar escrituras, por lo que no hay un líder de escritura único que fallar. - Si falla Redis en una región, el servicio de redirección recurre a la base de datos. La base de datos puede manejar la carga temporalmente y Redis se recupera rápidamente. - Si el pipeline de analíticas (Kafka) tiene problemas, los eventos de clics se almacenan en búfer. La durabilidad de Kafka asegura que no haya pérdida de datos. Que las analíticas sean eventualmente consistentes hasta 10 minutos nos da margen. - Se implementan disyuntores entre servicios. Si la base de datos es lenta, el servicio de redirección sirve desde la caché y degrada con gracia (devuelve resultados cacheados o un error temporal para fallos de caché). Comprobaciones de estado y monitorización: - Cada instancia de servicio tiene puntos finales de comprobación de estado. - Los balanceadores de carga eliminan las instancias no saludables automáticamente. - Monitorización integral con paneles para percentiles de latencia (p50, p95, p99), tasas de error, ratios de aciertos de caché y latencia de cola. - Alertas sobre violaciones de SLO. Durabilidad de los datos: - DynamoDB proporciona 99.999999999% de durabilidad con replicación entre regiones. - Copias de seguridad regulares como red de seguridad adicional. 8. ESCALADO PARA TRÁFICO INTENSIVO EN LECTURA Y PUNTOS CALIENTES VIRALES La relación lectura/escritura es aproximadamente 10:1 (1.200 millones de lecturas frente a 120 millones de escrituras por mes), pero durante eventos virales, un solo enlace puede recibir millones de visitas por hora. Estrategias: - El almacenamiento en caché en el borde de la CDN es la primera y más efectiva defensa. La respuesta de redirección de un enlace viral se almacena en caché en cientos de ubicaciones de borde en todo el mundo. Incluso un TTL de 5 minutos significa que el origen solo ve una solicitud cada 5 minutos por ubicación de borde. - La computación en el borde (Cloudflare Workers o Lambda@Edge) puede realizar la búsqueda de redirección completamente en el borde leyendo de un almacén KV distribuido (como Cloudflare KV o DynamoDB DAX), eliminando la necesidad de contactar al origen en absoluto. - Autoescalado del clúster de Redis: Monitorizar la carga de la caché y añadir réplicas de lectura dinámicamente. - Autoescalado del servicio de redirección: Los servicios sin estado escalan horizontalmente basándose en métricas de CPU y recuento de solicitudes. - Para puntos calientes extremos, la caché local a nivel de aplicación en cada instancia del servicio de redirección asegura que, incluso si Redis está bajo presión, los enlaces más populares se sirvan desde la memoria. Analíticas durante eventos virales: - Los eventos de clics se producen en Kafka, que maneja bien las escrituras ráfagas. - El consumidor de analíticas puede agrupar y agregar antes de escribir en el almacén de analíticas, reduciendo la amplificación de escritura. - Usamos conteo aproximado si es necesario (HyperLogLog para visitantes únicos), pero para clics totales, los contadores simples son suficientes. 9. PREVENCIÓN DE ABUSOS Medidas básicas (la confianza y seguridad completas están fuera del alcance): - Limitación de velocidad en la creación de enlaces: por IP y por usuario autenticado (por ejemplo, 100 enlaces por hora para anónimos, 1000 para autenticados). - Validación de URL: rechazar URL mal formadas, comprobar contra listas de bloqueo de URL de phishing/malware conocidas (por ejemplo, API de Google Safe Browsing). - Validación de alias personalizados: lista de bloqueo de palabras ofensivas y reservadas. - CAPTCHA para la creación anónima de enlaces si se acercan los límites de velocidad. - Capacidad para deshabilitar enlaces reportados como abusivos (manual o automatizado). - Registro y pista de auditoría para todos los eventos de creación de enlaces. 10. COMPENSACIONES CLAVE Consistencia vs. Latencia: - Elegimos la consistencia eventual para el mapeo de enlaces entre regiones. Un enlace recién creado podría no ser resoluble en una región distante durante unos cientos de milisegundos. Esto es aceptable porque el usuario que crea el enlace se dirige a la región más cercana donde la escritura es inmediatamente consistente, y la replicación entre regiones es rápida. Para analíticas, aceptamos explícitamente una consistencia eventual de 10 minutos. Redirecciones 302 vs. 301: - 302 (temporal) nos permite rastrear cada clic y cambiar destinos, pero aumenta la carga del origen. 301 (permanente) es más eficiente pero los navegadores la almacenan en caché indefinidamente. Nuestra solución: usar 302 desde el origen pero permitir el almacenamiento en caché en el borde de la CDN con un TTL corto, dándonos lo mejor de ambos mundos. Costo vs. Rendimiento: - El precio bajo demanda de DynamoDB es más caro por solicitud que el aprovisionado, pero maneja el tráfico ráfaga sin planificación de capacidad. Para un servicio a esta escala, usamos capacidad aprovisionada con autoescalado para la línea base y bajo demanda para el desbordamiento. - La CDN y la computación en el borde añaden costo pero reducen drásticamente las necesidades de infraestructura del origen y mejoran la experiencia del usuario. Complejidad Operacional vs. Fiabilidad: - El despliegue multirregión con DynamoDB Global Tables añade complejidad operacional pero es necesario para el objetivo de disponibilidad del 99,99% y el requisito de baja latencia global. - Kafka añade otro sistema para operar pero proporciona el desacoplamiento y la durabilidad necesarios para analíticas fiables. Almacenamiento vs. Computación: - Preagregamos los recuentos diarios de analíticas en lugar de computarlos sobre la marcha a partir de eventos de clics brutos. Esto intercambia eficiencia de almacenamiento por rendimiento de consulta y simplicidad. Unicidad del Alias Personalizado: - Los alias personalizados comparten el mismo espacio de nombres que los códigos generados. Reservamos el espacio de códigos generados (exactamente 7 caracteres base62) y requerimos que los alias personalizados tengan una longitud diferente o se comprueben contra el rango generado. Enfoque más simple: todos los códigos (generados y personalizados) van a la misma tabla, y la escritura condicional asegura la unicidad independientemente. 11. RESUMEN DE ELECCIONES TECNOLÓGICAS - Balanceo de Carga Global: AWS Global Accelerator o Cloudflare con DNS anycast - CDN y Borde: CloudFront o Cloudflare con trabajadores de borde - Computación: Clústeres de Kubernetes o ECS/Fargate en cada región para servicios sin estado - Base de Datos Principal: DynamoDB Global Tables (mapeos de enlaces y analíticas diarias) - Caché: Clústeres de Redis ElastiCache en cada región - Cola de Mensajes: Amazon Kinesis o Apache Kafka (MSK) para eventos de clics - Procesamiento de Analíticas: Kafka Streams o Flink para agregación en tiempo real - Generación de ID: Servicio de asignación basado en rangos respaldado por un pequeño almacén de coordinación (DynamoDB o ZooKeeper) - Monitorización: CloudWatch, Prometheus, Grafana, PagerDuty para alertas Este diseño maneja los requisitos declarados con una clara separación de la ruta de escritura (creación de enlaces), la ruta de lectura (redirecciones) y la ruta de analíticas, cada una escalable de forma independiente. La estrategia de caché en capas (borde, Redis regional, local) asegura que incluso el tráfico viral extremo se maneje con gracia, mientras que la arquitectura multirregión con DynamoDB Global Tables proporciona la durabilidad y las garantías de disponibilidad necesarias para un SLA del 99,99%.

### 1. Arquitectura de Alto Nivel El sistema está diseñado como una arquitectura multi-región distribuida globalmente para garantizar baja latencia y alta disponibilidad. Cada región actúa como un Punto de Presencia (PoP) autónomo. **Componentes Principales:** * **Balanceador de Carga Global (GLB):** Utiliza enrutamiento basado en DNS (por ejemplo, basado en latencia, basado en geografía) para dirigir a los usuarios a la región saludable más cercana. * **CDN (Red de Entrega de Contenido):** Se sitúa delante de nuestros servidores de aplicaciones para almacenar en caché las respuestas de redirección (HTTP 301) de enlaces populares en el borde, reduciendo drásticamente la latencia y la carga en nuestra infraestructura para contenido viral. * **Balanceador de Carga Regional:** Distribuye el tráfico dentro de una región a los servidores web sin estado. * **Servidores Web (API Gateway):** Terminan TLS y enrutan las solicitudes al servicio backend apropiado. * **Servicio de Redirección (Ruta de Lectura):** Un microservicio sin estado y altamente optimizado que maneja las solicitudes `GET /{short_id}`. Realiza una búsqueda (primero en caché, luego en base de datos) y emite una redirección. Este es el componente más crítico y de mayor tráfico. * **Servicio de Enlaces (Ruta de Escritura):** Un microservicio que maneja `POST /api/v1/links` para crear nuevos enlaces cortos. Se coordina con el Generador de IDs y escribe en la base de datos. * **Servicio de Analíticas:** Un microservicio que proporciona datos de analíticas a través de `GET /api/v1/links/{short_id}/analytics`. Lee de un almacén de datos de analíticas dedicado. * **Servicio Generador de IDs:** Un servicio dedicado (por ejemplo, basado en Snowflake) que genera IDs de 64 bits únicos globalmente y aproximadamente ordenables por tiempo para ser utilizados como enlaces cortos. * **Cola de Mensajes (por ejemplo, Kafka, AWS SQS):** Desacopla la ruta crítica de redirección del procesamiento no crítico de analíticas. El Servicio de Redirección publica un "evento de clic" ligero en la cola por cada redirección exitosa. * **Procesador de Ingesta de Analíticas:** Un servicio consumidor que lee de la cola de mensajes, procesa los eventos de clic y actualiza el almacén de datos de analíticas y los contadores agregados. *(Enlace al diagrama conceptual)* ### 2. Modelo de Datos y Elecciones de Almacenamiento Utilizaremos dos almacenes de datos separados optimizados para sus patrones de acceso específicos. **A. Almacén de Mapeo de Enlaces** * **Elección:** Un almacén de clave-valor NoSQL distribuido como **Amazon DynamoDB** con Tablas Globales o **Apache Cassandra**. * **Justificación:** Esta elección está impulsada por la necesidad de escalabilidad masiva, alta disponibilidad y búsquedas de baja latencia basadas en claves. El patrón de lectura principal es una búsqueda directa por `short_id`, que se ajusta perfectamente a un modelo de clave-valor. Una configuración multi-región y multi-maestro (como las Tablas Globales de DynamoDB) proporciona lecturas y escrituras de baja latencia para usuarios globales y recuperación ante desastres incorporada. * **Esquema (tabla `links`):** * `short_id` (String, Clave de Partición): El código único de 7 caracteres o alias personalizado. * `long_url` (String): La URL de destino. * `created_at` (Timestamp): Marca de tiempo de creación. * `total_clicks` (Number): Un contador atómico para los clics totales de por vida, actualizado por el procesador de analíticas. **B. Almacén de Datos de Analíticas** * **Elección:** Una base de datos de columnas anchas o series temporales como **Apache Cassandra** o **Amazon Timestream**. * **Justificación:** Este almacén necesita manejar un rendimiento de escritura muy alto de eventos de clic y consultar eficientemente los datos por rango de tiempo (por ejemplo, últimos 30 días). Un almacén de columnas anchas nos permite modelar esto de manera efectiva. * **Esquema (tabla `clicks_by_day`):** * `short_id` (String, Clave de Partición): El identificador del enlace. * `event_date` (String, Clave de Agrupación, formato `YYYY-MM-DD`): La fecha de los clics. * `daily_count` (Counter): Un contador distribuido para el número de clics en ese día. Este modelo pre-agregado es eficiente para la consulta requerida ("clics por día"). Los datos de eventos brutos podrían almacenarse en un almacén de objetos más económico (como S3) para archivo a largo plazo si fuera necesario. ### 3. Estrategia de Generación de IDs * **IDs Generados:** Necesitamos IDs cortos, únicos y no secuenciales. Una cadena de 7 caracteres que utiliza codificación Base62 (`[a-zA-Z0-9]`) proporciona 62^7 (~3.5 billones) combinaciones únicas, lo cual es más que suficiente para los 7.2 mil millones de enlaces esperados durante 5 años. 1. El **Servicio Generador de IDs** produce un entero de 64 bits único globalmente (similar al Snowflake de Twitter), que combina una marca de tiempo, un ID de región/máquina y un número de secuencia. Esto evita un punto único de fallo y contención. 2. El **Servicio de Enlaces** solicita un ID al generador. 3. Luego, codifica en Base62 el entero de 64 bits para crear la cadena `short_id`. * **Alias Personalizados:** 1. Cuando un usuario envía un alias personalizado, el Servicio de Enlaces realiza una lectura directa en la tabla `links` utilizando el alias como clave. 2. Si la clave no existe, procede a escribir la nueva entrada utilizando una escritura condicional (por ejemplo, `put if not exists`) para evitar condiciones de carrera donde dos usuarios reclaman el mismo alias simultáneamente. 3. Si la clave existe, devuelve un error 409 Conflict. ### 4. Diseño de la API El servicio expone una API RESTful simple. * **Crear Enlace Corto:** `POST /api/v1/links` * **Cuerpo de la Solicitud:** `{"long_url": "https://example.com/very/long/path", "custom_alias": "my-link"}` (custom_alias es opcional) * **Éxito (201 Created):** `{"short_url": "https://sho.rt/my-link", "long_url": "..."}` * **Error (409 Conflict):** Si el alias personalizado ya está ocupado. * **Redirigir Usuario:** `GET /{short_id}` * **Ejemplo:** `GET /aB1x2Yc` * **Éxito (301 Moved Permanently):** `Location: https://example.com/very/long/path` * **Error (404 Not Found):** Si el `short_id` no existe. * **Obtener Analíticas:** `GET /api/v1/links/{short_id}/analytics` * **Éxito (200 OK):** `{"short_id": "aB1x2Yc", "total_clicks": 15023, "daily_clicks": [{"date": "2023-10-27", "clicks": 850}, {"date": "2023-10-26", "clicks": 1200}]}` ### 5. Caché, Particionamiento y Replicación * **Caché:** Una estrategia de caché de múltiples capas es esencial para manejar el tráfico intensivo de lectura y los puntos calientes virales. 1. **Caché de CDN:** La CDN almacena en caché las respuestas de redirección `301` en el borde. Esta es la primera línea de defensa y maneja la mayor parte del tráfico para enlaces populares. 2. **Caché en Memoria:** Cada región tiene una caché distribuida (por ejemplo, **Redis Cluster**) que almacena mapeos de `short_id -> long_url`. El Servicio de Redirección sigue un patrón de lectura a través de: verificar Redis primero y, en caso de fallo, consultar la base de datos y poblar la caché con un TTL (por ejemplo, 24 horas). 3. **Caché Negativa:** Almacena en caché los resultados de "no encontrado" durante un corto período (por ejemplo, 5 minutos) para evitar búsquedas repetidas en la base de datos de enlaces inválidos o eliminados. * **Particionamiento:** Las bases de datos NoSQL (DynamoDB/Cassandra) particionan automáticamente los datos basándose en el hash de `short_id`. Esto distribuye la carga de datos y E/S horizontalmente a través del clúster, permitiendo una escala masiva. * **Replicación:** La base de datos principal de `links` se replica en todas las regiones activas en una configuración multi-maestro. Esto asegura que un enlace creado en una región esté rápidamente disponible para redirección en todas las demás regiones, proporcionando lecturas de baja latencia a nivel global y alta durabilidad de los datos. ### 6. Fiabilidad y Escalado * **Fiabilidad:** * **Activo-Activo Multi-Región:** Toda la pila se implementa en al menos tres regiones geográficamente separadas. El GLB realiza comprobaciones de estado y dirigirá automáticamente el tráfico lejos de cualquier región que falle, permitiendo que el servicio sobreviva a una interrupción regional completa. * **Servicios sin Estado:** Todos los servicios (Redirección, Enlace, Analíticas) no tienen estado, lo que permite escalarlos horizontalmente y reemplazarlos fácilmente si una instancia falla. * **Desacoplamiento:** La cola de mensajes garantiza que una ralentización o fallo en la canalización de analíticas no afecte la funcionalidad crítica de redirección que enfrenta el usuario. * **Escalado para Tráfico de Lectura:** 1. **CDN:** La CDN absorbe la mayoría de las solicitudes de enlaces virales. 2. **Escalado Horizontal:** El Servicio de Redirección sin estado se puede escalar añadiendo más instancias detrás del balanceador de carga regional. 3. **Escalado de Caché:** La caché distribuida se puede escalar añadiendo más nodos al clúster. 4. **Escalado de Base de Datos:** La base de datos NoSQL particionada escala añadiendo más nodos. ### 7. Compensaciones Clave * **Consistencia vs. Disponibilidad:** Priorizamos la Disponibilidad sobre la Consistencia Fuerte. El uso de una base de datos multi-maestro significa que los conflictos de escritura son posibles (aunque raros para este caso de uso). La consistencia eventual es aceptable para la propagación de enlaces entre regiones y es necesaria para los datos de analíticas (retraso de hasta 10 minutos). * **Costo vs. Rendimiento:** Una arquitectura global, multi-región, activo-activo con una CDN y múltiples almacenes de datos es costosa. Sin embargo, es necesaria para cumplir con los estrictos requisitos de disponibilidad del 99.99% y baja latencia global. Un diseño de región única más económico no sería suficiente. * **Complejidad Operacional:** La arquitectura de microservicios añade complejidad en términos de implementación, monitoreo y mantenimiento en comparación con un monolito. Esta compensación se realiza para lograr escalabilidad independiente, aislamiento de fallos y resiliencia para diferentes partes del sistema.