Diseñar un servicio de acortamiento de URL

A) Diseño de API 1) Crear URL corta - Endpoint: POST /v1/urls - JSON de solicitud: - long_url (cadena, requerido, máx. ej. 8 KB) - custom_alias (cadena, opcional; si se proporciona, debe ser único y pasar el conjunto de caracteres/longitud permitidos) - expire_at (marca de tiempo, opcional) - metadata (objeto, opcional: ej. campaña, user_id) - Respuesta (201): - code (cadena) - short_url (cadena) - long_url (cadena) - created_at (marca de tiempo) - expire_at (marca de tiempo|nulo) - Errores: - 400 URL/alias inválido - 409 alias ya existe - 429 límite de velocidad 2) Resolver/redireccionar - Endpoint: GET /{code} - Comportamiento: - 301 Movido Permanentemente por defecto (o 302 si el seguimiento/experimentación lo requiere) - Cabecera Location = long_url - Opcional: GET /v1/urls/{code} devuelve JSON en lugar de redireccionar (para clientes API) - Errores: - 404 no encontrado/expirado 3) Eliminar/deshabilitar (opcional, para control de abuso/usuario) - Endpoint: DELETE /v1/urls/{code} - Requiere autenticación - Respuesta: 204 4) Analíticas (opcional, puede ser asíncrono/aproximado) - Endpoint: GET /v1/urls/{code}/stats?from=&to= - Devuelve contadores agregados (clics por día, referente, geo, etc.) Notas: - Autenticación: Claves API/OAuth para creación y gestión; las redirecciones permanecen públicas. - Idempotencia: admite la cabecera Idempotency-Key en POST para evitar duplicados en reintentos. B) Modelo de Datos y Almacenamiento Carga de trabajo - Escrituras: 100M nuevas/mes ≈ 3.33M/día ≈ 38.6 escrituras/segundo en promedio (pico más alto). - Lecturas: 100:1 => 10B redirecciones/mes ≈ 3.86K lecturas/segundo en promedio (picos mucho más altos). Elección de almacenamiento - Almacén principal: almacén distribuido de clave-valor / columna ancha (ej. DynamoDB/Cassandra/ScyllaDB) optimizado para QPS de lectura muy alta, baja latencia, escalado horizontal y replicación multi-DC. - Justificación: el patrón de acceso es principalmente búsqueda por clave mediante código corto; el valor es pequeño; necesidad fuerte de alta disponibilidad y latencia predecible. - Sistemas secundarios: - Caché: clústeres Redis/Memcached por región. - Tubería de analíticas: Kafka/PubSub + procesamiento de flujos + almacén OLAP (no en la ruta crítica). Esquema 1) url_mapping (principal) - Clave de partición: code (cadena) - Columnas: - long_url (cadena) - created_at (marca de tiempo) - expire_at (marca de tiempo|nulo) - user_id (cadena|nulo) - status (activo/eliminado) - checksum (opcional para integridad) - TTL: si se establece expire_at, usar TTL nativo para que las entradas expiradas se eliminen automáticamente. 2) alias_reservation (opcional si se admiten alias personalizados con unicidad) - clave: custom_alias - valor: code / metadatos de propiedad 3) idempotency (opcional) - clave: (user_id, idempotency_key) - valor: code - TTL: ej. 24h Estimación de almacenamiento (10 años) - Nuevas URLs en 10 años: 100M/mes * 12 * 10 = 12 mil millones de mapeos. - Tamaño aproximado por registro: - code: ~8 bytes (o hasta ~10 caracteres) - long_url: asumir un promedio de 200 bytes (conservador), más sobrecarga - metadatos/columnas/sobrecarga de índice: asumir ~100–200 bytes dependiendo del almacén - Total efectivo (incluyendo sobrecarga de replicación aún no contada): ~400 bytes/registro (cifra de planificación razonable). - Datos brutos: 12 mil millones * 400 bytes = 4.8 TB. - Con sobrecarga del motor de almacenamiento + compactación + índices secundarios: planificar ~2–3x => ~10–15 TB. - Replicación: - Dentro de la región (RF=3): ~30–45 TB. - Multi-región (ej. 2 regiones activo-activo): duplicar => ~60–90 TB en total entre todas las regiones. (Estos son números de planificación; el exacto depende de la longitud promedio de la URL y la sobrecarga de la base de datos.) C) Generación de URL Corta Objetivos - Lo más corta posible - Libre de colisiones a gran escala - Soporta al menos 10 años de crecimiento Matemáticas del espacio de claves - Códigos totales necesarios en 10 años: 12 mil millones. - Usar conjunto de caracteres Base62: [0-9][a-z][A-Z] => 62 símbolos. - Capacidad de longitud L: 62^L. - 62^6 ≈ 56.8 mil millones (suficiente para 12 mil millones) - 62^7 ≈ 3.52 billones (más margen) Elección - Usar longitud variable con un mínimo de 6 caracteres. - Empezar con 6 caracteres para los primeros ~56.8 mil millones de códigos; eso ya cubre el requisito de 10 años con un margen significativo (56.8 mil millones / 12 mil millones ≈ 4.7x). - Mantener la capacidad de pasar a 7 caracteres en el futuro sin romper los enlaces existentes. Algoritmo de generación (sin colisiones) Opción seleccionada: IDs numéricos globalmente únicos + codificación Base62. - Mantener un espacio de IDs de 64 bits monótonamente creciente. - Codificar el ID en Base62 para producir el código. - Evitación de colisiones: no es necesaria porque los IDs son únicos por construcción. Cómo generar IDs a escala - Usar un asignador de IDs distribuido similar a Snowflake, o un “servicio de IDs” central con asignación de rangos: 1) El servicio de IDs almacena un contador en un almacén fuertemente consistente (ej. etcd/Spanner) por región. 2) Cada servidor de aplicaciones solicita un bloque de IDs (ej. 1 millón de IDs) para generar localmente. 3) Cuando el bloque se agota, solicita un nuevo bloque. - Esto evita la contención por escritura por cada operación, al tiempo que garantiza la unicidad. Manejo de alias personalizados - Si se proporciona custom_alias: - Validar conjunto de caracteres/longitud - Escritura condicional (comparar y establecer) en url_mapping con clave=alias; si existe, devolver 409. D) Escalado y Rendimiento Arquitectura de alto nivel - Anycast/GeoDNS -> Balanceador de Carga Global -> Balanceadores de Carga L7 Regionales -> servidores API/redirección sin estado. - Servicios separados: - Ruta de escritura: servicio de creación de URL - Ruta de lectura: servicio de redirección - Almacenamiento compartido + caché Escalado de lecturas y escrituras independientemente - Servicio de redirección escalado horizontalmente según QPS/latencia (probablemente el costo dominante). - Servicio de creación escalado según el rendimiento de escritura. - Usar grupos de escalado automático separados y canalizaciones de despliegue independientes. Particionamiento de datos - Particionar por hash del código (o por el código mismo) entre los nodos de la base de datos. - Distribución uniforme porque los códigos son efectivamente uniformes sobre el espacio de IDs cuando se codifican en Base62. Estrategia de caché - Principal: caché CDN/edge para redirecciones + caché en memoria regional. 1) CDN: - Caché de respuestas 301/302 indexadas por ruta (código) con TTL (ej. 5–60 minutos, o respetar expire_at). - Para enlaces extremadamente populares, la CDN puede absorber la mayor parte del tráfico a nivel mundial. 2) Caché regional (Redis/Memcached): - Clave: code - Valor: long_url + expire_at + status - TTL: min(default_ttl, expire_at-now) - Evicción: LRU o LFU (preferir LFU para popularidad sesgada). Tasa de aciertos esperada - Los accesos a URL suelen estar muy sesgados (Zipf). Con CDN + caché regional, es factible una tasa de aciertos del 95–99% para redirecciones; incluso un 90% es útil. - Calentamiento de caché: al escribir, enviar el mapeo a la caché; también caché negativa para fallos (TTL corto) para reducir los accesos repetidos a la base de datos para códigos inválidos. Cumplimiento de latencia de redirección p95 <50 ms - Ruta crítica para acierto de caché: - Acierto de Edge/CDN: a menudo <20 ms. - Acierto de caché regional: LB + app + búsqueda de Redis + respuesta: típicamente 5–15 ms dentro de la región. - Para fallo de caché: - Lectura única de la base de datos desde la réplica de la región local: objetivo 5–20 ms. - Mantener los servidores de redirección cerca de los usuarios mediante multi-región + edge. - Usar keep-alive, HTTP/2 entre componentes, agrupación de conexiones a Redis/DB. - Evitar analíticas síncronas; emitir eventos de clic asíncronamente a una cola. Rendimiento de escritura - Las escrituras son bajas en comparación con las lecturas; aún así, manejar ráfagas. - Flujo de escritura: 1) Generar ID/código 2) Escribir en la base de datos (quorum/mayoría dentro de la región) 3) Escritura directa a la caché 4) Devolver respuesta - Opcional: deduplicar long_url idénticas almacenando un índice hash->código (compensación; ver F). E) Fiabilidad y Tolerancia a Fallos Objetivo de disponibilidad: 99.9% - Multi-AZ dentro de cada región para todos los componentes con estado. - Al menos dos regiones activo-activo para el tráfico de redirección. Estrategia de replicación - Dentro de la región: factor de replicación 3 entre AZs. - Entre regiones: - Replicación asíncrona para url_mapping para mantener baja la latencia de escritura y alta la disponibilidad. - Las redirecciones se sirven desde la región local; si falta el mapeo local debido a retraso en la replicación, recurrir a otra región (ver abajo). Manejo de fallos de centro de datos/región (degradación elegante) - Usar comprobaciones de estado del Balanceador de Carga Global: - Si una región no está en buen estado, dirigir el tráfico a la siguiente región saludable más cercana. - Para solicitudes de redirección: - Si la caché/base de datos regional está degradada, el servicio de redirección puede: 1) Intentar la caché 2) Intentar la base de datos local 3) Si la base de datos local no está disponible, consultar un punto final de lectura de región remota (con tiempo de espera estricto) o usar una réplica de lectura entre regiones. 4) Si todo falla, devolver un 503 rápido con Retry-After (fallo elegante). - Para solicitudes de escritura: - Preferir escrituras en la región local; si la región está caída, conmutar a otra región. - Asignación de IDs: cada región tiene su propio espacio de nombres de bloque de IDs (o usa bits de región en Snowflake) para evitar conflictos durante la conmutación por error. Compensación del teorema CAP - Elegir Disponibilidad sobre Consistencia Fuerte para operaciones globales: - Las redirecciones deben estar altamente disponibles; las lecturas obsoletas son aceptables brevemente. - La replicación entre regiones es asíncrona: una URL corta recién creada podría no ser legible en otra región durante una breve ventana. Mitigaciones: - Después de la creación, devolver una URL corta alojada en el dominio de la misma región (o usar un edge que dirija a la región de origen durante los primeros minutos). - Al crear, opcionalmente hacer una escritura síncrona a dos regiones para clientes premium/empresariales (mayor latencia/costo). Copias de seguridad y recuperación ante desastres - Instantáneas periódicas + copias de seguridad incrementales a almacenamiento de objetos. - Simulacros de restauración regulares. F) Discusión de Compensaciones 1) Generación de códigos basada en IDs vs tokens aleatorios - Elegido: basado en IDs (rango asignado/Snowflake) + Base62. - Ganancias: - Sin colisiones, sin necesidad de bucles de reintento. - Planificación de capacidad predecible y restricciones de base de datos más simples. - Escrituras más rápidas. - Sacrificios: - Los códigos son adivinables/secuenciales (no se proporciona seguridad por oscuridad). Mitigación: - Añadir una “permutación con sal” opcional (ej. red Feistel) sobre el ID numérico antes de la codificación Base62 para hacer los códigos no secuenciales, preservando la unicidad. 2) Replicación asíncrona entre regiones (AP) vs multi-región síncrona (CP) - Elegido: replicación asíncrona entre regiones. - Ganancias: - Menor latencia de escritura, mayor disponibilidad durante fallos parciales. - Mejor capacidad para seguir sirviendo redirecciones incluso si una región está afectada. - Sacrificios: - Consistencia eventual: ventana breve donde una URL recién creada puede no ser legible en otra región. Mitigación: - Reparación de lectura/fallback a la región de origen para enlaces nuevos; escritura doble opcional para clientes con alto SLA. 3) Caching intensivo/CDN vs acceso siempre a la base de datos - Elegido: CDN + caché regional. - Ganancias: - Cumple fácilmente <50 ms p95 y reduce drásticamente la carga de la base de datos. - Maneja picos de tráfico para enlaces virales. - Sacrificios: - Complejidad de invalidación de caché (ej. enlaces eliminados/expirados). Mitigación: - TTL cortos, respetar expire_at, y purga explícita al eliminar para CDN donde sea compatible; usar banderas de estado y caché negativa con cuidado.

A) Diseño de API: 1. **Punto de acceso para acortar URL:** * **Método:** `POST` * **Ruta:** `/shorten` * **Cuerpo de la Solicitud (JSON):** ```json { "long_url": "string", "custom_short_code": "string" (opcional), "expires_at": "cadena de fecha y hora en formato ISO 8601" (opcional) } ``` * **Cuerpo de la Respuesta (JSON - 201 Creado):** ```json { "short_url": "string", "long_url": "string", "custom_short_code": "string" (si se proporcionó), "expires_at": "cadena de fecha y hora en formato ISO 8601" (si se proporcionó) } ``` * **Respuestas de Error:** * `400 Solicitud incorrecta`: Formato de `long_url` inválido o faltante. * `409 Conflicto`: `custom_short_code` ya existe. * `500 Error interno del servidor`: Error general del servidor. 2. **Punto de acceso para redirigir URL corta:** * **Método:** `GET` * **Ruta:** `/{shortCode}` * **Respuesta:** Redirección HTTP `302 Encontrado` a la `long_url`. * **Respuestas de Error:** * `404 No encontrado`: `shortCode` no existe o ha expirado. * `500 Error interno del servidor`: Error general del servidor. B) Modelo de Datos y Almacenamiento: **Elección de Almacenamiento:** Una base de datos relacional fragmentada (por ejemplo, PostgreSQL) con réplicas de lectura. **Justificación:** * **Consistencia Fuerte para Escrituras:** Esencial para garantizar la unicidad de los códigos cortos. Las bases de datos relacionales proporcionan propiedades ACID, cruciales para la integridad de datos confiable durante la creación de URL. * **Fragmentación Bien Comprendida:** PostgreSQL admite varias estrategias de fragmentación (por ejemplo, basada en rangos, basada en hash) para distribuir la carga de escritura y escalar horizontalmente. * **Indexación Eficiente:** Los índices B-tree son altamente eficientes para búsquedas puntuales en `short_code`, que es la operación principal para las redirecciones. * **Réplicas de Lectura:** Admite fácilmente la escalabilidad de las operaciones de lectura (redirecciones) añadiendo múltiples réplicas de solo lectura. * **Madurez y Ecosistema:** Herramientas robustas para monitoreo, copias de seguridad y recuperación. **Esquema:** Tabla `urls`: * `id`: BIGINT, Clave Primaria, Autoincremental (o generado por un servicio de ID distribuido). Se utiliza como base para el código corto. * `short_code`: VARCHAR(7), Índice Único, NO NULO. La cadena corta real utilizada en la URL. * `long_url`: TEXT, NO NULO. La URL larga original. * `created_at`: TIMESTAMP WITH TIME ZONE, NO NULO, Por defecto: `NOW()`. * `expires_at`: TIMESTAMP WITH TIME ZONE (nulo). Cuándo debe expirar la URL corta. * `user_id`: BIGINT (nulo, clave externa a una tabla `users` si se admiten cuentas de usuario). **Estimación de Almacenamiento (más de 10 años):** * **Volumen:** 100 millones de URL nuevas/mes * 12 meses/año * 10 años = 12 mil millones de URL. * **Estimación del Tamaño del Registro:** * `id`: 8 bytes (BIGINT) * `short_code`: 7 bytes (VARCHAR(7)) * `long_url`: Promedio 100 bytes (TEXT, longitud variable) * `created_at`: 8 bytes (TIMESTAMP) * `expires_at`: 8 bytes (TIMESTAMP) * Total por registro: ~131 bytes. * **Tamaño de Datos Crudos:** 12 mil millones de registros * 131 bytes/registro = 1.572 TB. * **Con Índices y Sobrecarga:** Teniendo en cuenta los índices (especialmente en `short_code` e `id`), la replicación y la sobrecarga de la base de datos, el almacenamiento total podría ser de aproximadamente 3-5 TB durante 10 años. Esto es manejable con una arquitectura de base de datos fragmentada. C) Generación de URL Corta: **Algoritmo:** 1. Cuando llega una solicitud para acortar una nueva URL, se obtiene un ID único y monotónicamente creciente. Este ID se puede generar mediante: * **Autoincremento de Base de Datos:** Si se utiliza una base de datos fragmentada, cada fragmento puede configurarse con un rango de ID único (por ejemplo, el fragmento 1 usa los ID 1, 11, 21..., el fragmento 2 usa 2, 12, 22...). * **Generador de ID Distribuido:** Un servicio dedicado como Snowflake (o una implementación personalizada similar) puede generar enteros de 64 bits globalmente únicos y ordenados por tiempo. 2. Este ID único se convierte luego a una cadena base62. Base62 utiliza 62 caracteres (0-9, a-z, A-Z), lo que permite una representación compacta. **Evitación de Colisiones:** * Al derivar el código corto de un ID globalmente único (ya sea mediante autoincremento fragmentado o un generador de ID distribuido), las colisiones se evitan inherentemente. Cada ID generado es único y su representación base62 también lo será. * Para las solicitudes de `custom_short_code`, el sistema intenta insertar el código proporcionado por el usuario. Si ocurre un conflicto (debido a una entrada existente), se devuelve un error `409 Conflicto` al usuario. **Conjunto de Caracteres y Longitud:** * **Conjunto de Caracteres:** Base62 (0-9, a-z, A-Z) - 62 caracteres únicos. * **Longitud:** 6 caracteres inicialmente. **Justificación Matemática para Suficiencia del Espacio de Claves:** * **Volumen Requerido:** 12 mil millones de URL únicas durante 10 años. * **Espacio de Claves con 6 caracteres:** 62^6 = 56,800,235,584 (aproximadamente 56.8 mil millones de códigos únicos). * Este espacio de claves (56.8 mil millones) es significativamente mayor que los 12 mil millones requeridos, proporcionando espacio suficiente para el crecimiento y garantizando suficiencia durante al menos 10 años. Si el servicio superara esto, la longitud del código corto podría extenderse a 7 caracteres, proporcionando 62^7 (aproximadamente 3.5 billones) de códigos únicos. D) Escalabilidad y Rendimiento: **Escalado de Lecturas (Redirecciones):** * **Caché Distribuida (por ejemplo, Redis Cluster):** El principal mecanismo de escalado para lecturas. Las asignaciones de `short_code` a `long_url` se almacenan en una caché distribuida y altamente disponible. Dada la relación de lectura/escritura de 100:1, la mayoría de las solicitudes de redirección se servirán directamente desde la caché. * **Réplicas de Lectura de Base de Datos:** Las instancias fragmentadas de PostgreSQL tendrán múltiples réplicas de lectura. En caso de fallo de caché, la solicitud recurre a una réplica de lectura. Los balanceadores de carga distribuyen las consultas entre estas réplicas. * **Red de Entrega de Contenido (CDN):** Aunque no almacena en caché directamente la redirección 302, una CDN puede servir activos estáticos y potencialmente optimizar el enrutamiento para las solicitudes iniciales, reduciendo la latencia para usuarios geográficamente dispersos. **Escalado de Escrituras (Acortamientos):** * **Fragmentación de Base de Datos:** La estrategia principal. Los datos se particionan en múltiples instancias de PostgreSQL basándose en una clave de fragmentación (por ejemplo, el `id` del que se deriva el `short_code`). Esto distribuye la carga de escritura y los requisitos de almacenamiento. * **Agrupación de Conexiones:** Gestiona eficientemente las conexiones a la base de datos para reducir la sobrecarga. * **Procesamiento Asíncrono:** Para tareas no críticas (por ejemplo, análisis, registro, actualización de estadísticas), las colas de mensajes (por ejemplo, Kafka, RabbitMQ) pueden descargar trabajo de la ruta de escritura principal, mejorando la capacidad de respuesta. **Estrategia de Caché:** * **Tipo de Caché:** Caché distribuida en memoria (por ejemplo, Redis Cluster). * **Datos Almacenados en Caché:** Asignaciones de `short_code` a `long_url`. * **Población de Caché:** Tras un acortamiento de URL exitoso, la nueva asignación se escribe tanto en la base de datos como en la caché. En un fallo de caché durante una redirección, la asignación se recupera de la base de datos y luego se escribe en la caché (write-through/write-aside). * **Política de Evicción:** LRU (Least Recently Used - Menos Usado Recientemente) es adecuada. Las URL populares permanecerán en la caché, mientras que las de acceso menos frecuente se eviccionarán para hacer espacio. También se puede aplicar un Tiempo de Vida (TTL), especialmente para URL con un campo `expires_at`. * **Tasa de Éxito Esperada:** Dada la relación de lectura/escritura de 100:1 y la distribución de ley de potencias del acceso a URL (un pequeño porcentaje de URL representa un gran porcentaje del tráfico), una tasa de éxito de caché del 90-95%+ es muy alcanzable, reduciendo significativamente la carga de la base de datos. **Cumplimiento del Requisito de Latencia p95 de 50 ms:** * **Alta Tasa de Éxito de Caché:** La gran mayoría de las solicitudes de redirección se servirán desde la caché distribuida, que puede responder en milisegundos de un solo dígito. * **Acceso Optimizado a la Base de Datos:** Para fallos de caché, la indexación eficiente en `short_code` en la base de datos fragmentada garantiza búsquedas rápidas. * **Proximidad y Red:** Despliegue de servicios en múltiples regiones cercanas a los usuarios y utilización de infraestructura de red de alta velocidad y baja latencia. * **Balanceo de Carga:** Distribución eficiente de solicitudes entre instancias de servicio y réplicas de base de datos saludables. * **Servidores de Aplicaciones sin Estado:** Permite escalar fácilmente la capa de API horizontalmente, asegurando suficiente capacidad para manejar cargas pico sin convertirse en un cuello de botella. D) Fiabilidad y Tolerancia a Fallos: **Fallos de Centros de Datos:** * **Despliegue Multi-Región:** Todo el servicio (servidores API, clústeres de caché, fragmentos de base de datos) se despliega en al menos dos centros de datos/regiones geográficamente distintas. * **Balanceador de Carga Global (por ejemplo, gestión de tráfico basada en DNS):** Dirige el tráfico de usuarios a la región saludable más cercana. Si una región falla, el tráfico se redirige automáticamente a la región operativa. * **Conmutación por Error Automática:** Los clústeres de bases de datos se configuran para conmutación por error automática dentro de una región (primaria a réplica) y entre regiones (configuración activa-pasiva o activa-activa). **Estrategia de Replicación de Datos:** * **Base de Datos (PostgreSQL):** * **Dentro de una Región:** Se utiliza replicación de streaming síncrona entre la instancia de base de datos primaria y sus réplicas locales. Esto garantiza cero pérdida de datos en caso de fallo de la primaria dentro del mismo centro de datos. * **Entre Regiones:** Se utiliza replicación de streaming asíncrona desde la primaria en la región activa a una réplica en la región pasiva/en espera. Esto proporciona capacidades de recuperación ante desastres con un impacto mínimo en el rendimiento de la ruta de escritura principal. En una configuración activa-activa, la primaria de cada región replicaría asíncronamente a la otra. * **Caché Distribuida (Redis Cluster):** Los datos se fragmentan y replican en múltiples nodos dentro de cada clúster de Redis. Cada fragmento tiene una primaria y al menos una réplica. En caso de fallo de un nodo, una réplica se promueve a primaria. **Compromisos (Teorema CAP):** * **Elección:** Priorizar la **Disponibilidad (A)** y la **Tolerancia a Particiones (P)** sobre la **Consistencia (C)** fuerte para las operaciones de lectura (redirecciones), manteniendo la consistencia fuerte para las operaciones de escritura (acortamiento) dentro de un fragmento de base de datos. * **Justificación:** Para un servicio de acortamiento de URL, es más crítico que el servicio permanezca disponible y receptivo (baja latencia) incluso durante particiones de red o fallos de centros de datos. Los usuarios esperan que las redirecciones funcionen rápidamente. * **Cómo se logra:** * **Disponibilidad:** El despliegue multi-región, el balanceo de carga global, las réplicas de lectura de bases de datos y una caché distribuida altamente disponible garantizan que las solicitudes siempre puedan ser atendidas. * **Tolerancia a Particiones:** La naturaleza distribuida del sistema (fragmentación, replicación) maneja inherentemente las particiones de red. * **Consistencia:** Para las escrituras, se mantiene la consistencia fuerte dentro de un fragmento de base de datos. La replicación entre regiones es asíncrona, lo que significa que puede haber una pequeña ventana de inconsistencia entre regiones para las URL recién creadas. La caché también sirve como una capa de consistencia eventual, ya que se actualiza en las escrituras y en los fallos de caché. F) Discusión de Compromisos: 1. **Consistencia vs. Disponibilidad para Redirecciones (Teorema CAP):** * **Elección:** Priorizar la **Disponibilidad** y la **Tolerancia a Particiones** sobre la **Consistencia Fuerte** inmediata para la ruta de redirección. * **Por qué:** El objetivo principal de un acortador de URL es proporcionar redirecciones rápidas y confiables. Si una URL recién creada tarda unos segundos en propagarse a todas las réplicas de lectura y cachés a nivel mundial, es una inconveniencia menor. Sin embargo, si el sistema esperara la consistencia global antes de servir una redirección, introduciría una latencia significativa y reduciría la disponibilidad durante particiones de red o fallos regionales. Los usuarios preferirían experimentar un raro 404 para una URL nueva que tiempos de espera o redirecciones lentas frecuentes. * **Sacrificio:** Una pequeña ventana de consistencia eventual. Un usuario podría crear una URL en la Región A y, si intenta acceder a ella inmediatamente desde la Región B (antes de que se complete la replicación asíncrona), podría recibir temporalmente un 404. En escenarios extremos de fallo multi-región con replicación asíncrona, existe un pequeño riesgo de pérdida de datos para escrituras muy recientes si la región primaria falla catastróficamente antes de que la replicación a la región secundaria se complete. * **Ganancia:** Alta disponibilidad (99.9% de tiempo de actividad) y latencia extremadamente baja (p95 inferior a 50 ms) para la gran mayoría de las solicitudes de redirección, que son las operaciones más frecuentes. El sistema permanece operativo y receptivo incluso si un centro de datos se desconecta. 2. **Método de Generación de Código Corto (ID Secuencial a Base62 vs. Hash de URL Larga):** * **Elección:** Generar códigos cortos convirtiendo un ID único y secuencialmente creciente (de un generador de ID distribuido o autoincremento fragmentado) a Base62. * **Por qué:** Este método garantiza la unicidad por diseño, simplificando la ruta de escritura y mejorando el rendimiento. Evita las complejidades y la sobrecarga de rendimiento asociadas con la detección y resolución de colisiones inherentes a los enfoques basados en hash. * **Sacrificio:** Los códigos cortos pueden parecer algo secuenciales (por ejemplo, `abcde1`, `abcde2`) en lugar de completamente aleatorios. Esto podría ser una preocupación estética menor para algunos usuarios, pero no afecta la funcionalidad. Además, requiere un mecanismo robusto de generación de ID distribuido, lo que añade un componente a la arquitectura. * **Ganancia:** * **Unicidad Garantizada:** Sin colisiones, eliminando la necesidad de búsquedas en la base de datos y reintentos durante la generación del código corto, lo cual es crítico para un alto rendimiento de escritura (100M/mes). * **Ruta de Escritura Más Simple:** El proceso de creación de una nueva URL corta es una operación de inserción sencilla después de la generación del ID. * **Espacio de Claves Predecible:** Más fácil de gestionar y asegurar que el espacio de claves sea suficiente para el crecimiento futuro. * **Flexibilidad:** Permite que la misma `long_url` se acorte varias veces, produciendo diferentes `short_code` si se desea (por ejemplo, para rastrear diferentes campañas), lo cual no es posible con un simple hash de la `long_url`.