Diseñar un servicio de acortamiento de URLs

A. Estrategia de generación de códigos cortos 1. Elección basada en requisitos - Nuevas escrituras: 100M/mes ≈ 3.3M/día ≈ 38.6 escrituras/segundo en promedio. - Lecturas en relación 100:1 ≈ 3.3B/mes ≈ 1,270 lecturas/segundo en promedio, con picos probablemente 10–50 veces mayores. - Necesitamos identificadores compactos, globalmente únicos y con búsqueda muy rápida. 2. Enfoque de generación de código Usaría un servicio de generación de ID determinista más codificación Base62. Flujo: - Se genera un ID numérico globalmente único. - Ese entero se codifica en Base62 usando los caracteres [0-9a-zA-Z]. - Ejemplo: 125 -> "21" en Base62. Por qué este enfoque: - Sin riesgo de colisión si los ID son únicos. - Muy rápido de generar. - Fácil de operar en comparación con la verificación de colisiones de códigos aleatorios. - Crecimiento predecible de la longitud del código. 3. Diseño del generador de ID Opción preferida: - Usar un generador de ID de 64 bits estilo Snowflake o un asignador de rangos centralizado. - Los campos de ID pueden incluir marca de tiempo + ID de máquina + secuencia, o podemos asignar rangos monótonamente crecientes a los servidores de aplicaciones. Dos buenas implementaciones: - ID estilo Snowflake: descentralizados, alto rendimiento, baja coordinación. - Asignación de rangos desde un almacén de metadatos: cada nodo de escritura alquila un bloque de ID, por ejemplo, 1M de ID a la vez. Prefiero la asignación de rangos por simplicidad, ya que el rendimiento de escritura es modesto. Cada servidor de escritura puede generar ID localmente desde su rango alquilado, evitando una dependencia centralizada crítica. 4. Esquema de codificación y longitud esperada Capacidad Base62: - 62^6 ≈ 56.8B - 62^7 ≈ 3.52T Enlaces totales durante 5 años: - 100M/mes * 60 meses = 6B enlaces Por lo tanto, 6 caracteres Base62 no son suficientes para tener margen a largo plazo si los ID se usan de forma densa a nivel mundial, pero 7 caracteres son más que suficientes. Longitud esperada: - Comenzar con 6 caracteres para el ciclo de vida inicial si se desea. - En la práctica, estandarizar en 7 caracteres para mantener la implementación simple y evitar cambios de longitud en las expectativas del usuario. 5. Manejo de colisiones Con ID únicos deterministas: - Sin colisiones a nivel de código. - La restricción de unicidad de la base de datos en `short_code` proporciona una red de seguridad final. - Si se observa un duplicado muy raro debido a un error de software o una mala configuración del ID, regenerar a partir de un ID nuevo y alertar. 6. Estrategia de agotamiento - Base62 de 7 caracteres proporciona 3.52 billones de combinaciones, mucho más allá de los 6B necesarios en 5 años. - Si la escala futura crece sustancialmente, admitir códigos de 8 caracteres sin problemas. - El servicio de redirección debe tratar la longitud del código como variable, por lo que no habrá problema de migración. 7. Alias personalizados opcionales Si el producto admite alias definidos por el usuario: - Almacenar en la misma tabla de mapeo con unicidad forzada. - Reservar palabras bloqueadas y términos abusivos. - Aplicar límites de velocidad más estrictos, ya que los alias personalizados son un punto de contención. B. Almacenamiento de datos 1. Elección de la base de datos principal Usar un almacén de clave-valor distribuido y altamente disponible para el mapeo de URL, como: - DynamoDB / Bigtable / Cassandra Por qué: - El patrón de acceso principal es una simple búsqueda por clave usando `short_code`. - Necesidad de escalado horizontal, alta disponibilidad y lecturas multireplica. - Las escrituras son modestas, las lecturas son dominantes. - El acceso clave-valor es ideal para latencias de redirección inferiores a 50 ms. Elegiría un almacenamiento tipo DynamoDB o Cassandra conceptualmente: - Particionar por hash de `short_code`. - Replicar entre zonas de disponibilidad. - Optimizar para lecturas puntuales de baja latencia. 2. Almacenes secundarios - Base de datos relacional para metadatos del plano de control, facturación, usuarios, dominios, políticas. - Almacenamiento de objetos + data lake para análisis/registros de clics. - Almacén de búsqueda/índice opcional si los administradores necesitan consultar por creador, fecha, etiquetas, etc. 3. Diseño del esquema Tabla de mapeo principal: - `short_code` (PK) - `destination_url` - `created_at` - `expires_at` (nullable) - `owner_id` (nullable) - `status` (activo, deshabilitado, eliminado) - `redirect_type` (301/302) - `checksum` o `normalized_url` hash (opcional) - `metadata pointer` (opcional) Tabla de deduplicación opcional si el producto desea que la misma URL larga devuelva la misma URL corta por inquilino: - `dedup_key` = hash(`tenant_id` + `canonicalized_url`) - `short_code` Esto es opcional; muchos acortadores de URL no deduplican globalmente porque la semántica difiere según el usuario, la campaña o las necesidades analíticas. 4. Estimación de almacenamiento durante 5 años Enlaces totales: - 6B registros Estimación aproximada por registro: - `short_code`: ~8 bytes de equivalente en bruto - `destination_url`: asumir un promedio de 200 bytes - marcas de tiempo/estado/banderas: ~24 bytes - sobrecarga de replicación/versionado/índice: sustancial en sistemas reales - sobrecarga del motor de almacenamiento: asumir un total efectivo de ~350–500 bytes por registro en la base de datos principal Usando 400 bytes/registro: - 6B * 400 bytes = 2.4 TB de datos lógicos brutos Con factor de replicación 3: - 7.2 TB Agregar índices, sobrecarga de compactación, marcadores de tumba, metadatos, margen operativo: - Planificar entre 10 y 15 TB en almacenamiento principal durante 5 años Los registros de análisis/clics son mucho más grandes que los mapeos. Con 100 lecturas por escritura: - 600B redirecciones durante 5 años Si cada evento de registro de clics promediara incluso 100 bytes comprimidos, eso serían ~60 TB comprimidos, probablemente mucho más con campos más ricos. Por lo tanto, los registros deben ir a almacenamiento de objetos económico, no a la base de datos de servicio. 5. Estrategia de particionamiento/fragmentación Fragmentación de la tabla principal: - Clave de partición: `short_code` o hash(`short_code`) - Distribución uniforme porque los ID se codifican a partir de ID numéricos bien distribuidos o ID de rango mezclados apropiadamente Nota importante: - Los ID puramente secuenciales pueden crear particiones calientes en algunas bases de datos si la localidad de la clave es importante. - Para evitar esto, ya sea: 1. Hash del `short_code` para la ubicación de la partición, o 2. Usar ID con suficiente entropía en los bits inferiores, o 3. Prefijar con bits de fragmento antes de la codificación Base62 Yo particionaría explícitamente por hash en `short_code` para garantizar una distribución uniforme. C. Arquitectura de la ruta de lectura 1. Descripción general de la ruta de lectura Flujo de solicitud: - El usuario accede a https://sho.rt/abc1234 - DNS dirige al borde/CDN más cercano - El CDN reenvía al servicio de redirección regional si no hay caché - El servicio de redirección verifica la caché en memoria/Redis - En caso de fallo de caché, lee del almacén KV distribuido - Devuelve HTTP 301/302 con la cabecera `Location` - Emite de forma asíncrona el evento de clic al pipeline de análisis 2. Cumplimiento de latencia p95 <50 ms La ruta de redirección debe ser extremadamente ligera. Ejemplo de presupuesto de latencia: - Enrutamiento Edge/CDN: pequeño, geográficamente local - Procesamiento de aplicaciones: 1–3 ms - Éxito de caché en memoria/Redis: 1–5 ms - Ruta de fallo de DB dentro de la región: 5–15 ms típico - El p95 total por debajo de 50 ms es factible con servicio regional y almacenamiento en caché agresivo 3. Capas de caché Capa 1: Caché CDN/borde - Almacenar en caché las respuestas de redirección para enlaces populares en el borde. - Muy efectivo porque muchos enlaces cortos populares se acceden repetidamente. - Usar cabeceras `cache-control` con TTL, por ejemplo, minutos a horas según la mutabilidad. - Si los enlaces se pueden deshabilitar rápidamente, elegir un TTL más corto o soporte de purga. Capa 2: Caché local de la aplicación - Cada nodo de redirección mantiene una caché LRU de mapeos populares. - Latencia ultra baja, evita el salto de red a Redis. - Bueno para los códigos solicitados con más frecuencia. Capa 3: Caché distribuida (Redis/Memcached) - Caché compartida para la flota regional. - Almacena `short_code` -> `destination_url`, estado, tipo de redirección. - El TTL puede ser largo para enlaces inmutables; más corto para enlaces mutables/controlados por administrador. 4. Estrategia de replicación para lecturas - Réplicas Multi-AZ dentro de cada región. - Servir lecturas desde réplicas de almacenamiento de la región local. - Activo-activo entre múltiples regiones para tráfico global. - Usar geo-DNS o Anycast para dirigir a la región saludable más cercana. 5. Estrategia de población de caché - Lectura directa en caso de fallo: la aplicación recupera de la DB, puebla Redis y la caché local. - Caché negativa para códigos inexistentes/deshabilitados con TTL corto para absorber abusos y errores tipográficos. - Precalentar la caché para enlaces de tendencia si se conocen por análisis. 6. Semántica de redirección - 302 por defecto si el destino puede cambiar o si las políticas de análisis/seguimiento requieren flexibilidad. - 301 para enlaces permanentes donde los clientes y las CDN pueden almacenar en caché de forma agresiva. - La decisión del producto puede exponer ambas opciones. 7. Manejo de abusos en la ruta de lectura - Limitar la velocidad por IP / ASN / token para solicitudes sospechosas de alta velocidad. - WAF y filtros de bots en la CDN. - Proteger el origen contra escaneo de códigos cortos por fuerza bruta. D. Arquitectura de la ruta de escritura 1. Descripción general de la ruta de escritura Flujo de solicitud: - El cliente envía la URL larga y metadatos opcionales/alias personalizado. - La pasarela API autentica y limita la velocidad. - La validación y normalización de URL ocurren en el nivel de aplicación sin estado. - La aplicación obtiene/genera el código corto. - Persiste el mapeo en el almacén KV principal. - Puebla las cachés de forma asíncrona o síncrona para disponibilidad inmediata. - Emite el evento de creación a la cola para análisis, escaneo de abusos e indexación posterior. 2. Capacidad 100M/mes no es alto para sistemas modernos: - Promedio de ~39 escrituras/segundo - Incluso un estallido de 100x son solo unos pocos miles de escrituras/segundo Por lo tanto, los objetivos principales son la confiabilidad, la idempotencia y la simplicidad operativa, en lugar de un rendimiento de escritura extremo. 3. Pasos de validación - Validar la sintaxis de la URL. - Forzar protocolos permitidos, generalmente solo http/https. - Escaneo asíncrono opcional de navegación segura o malware; si se encuentra riesgo, deshabilitar el enlace. - Canonicalizar la URL para la deduplicación opcional. 4. Colas y trabajo asíncrono Usar una cola o registro duradero como Kafka/SQS/PubSub para efectos secundarios: - Evento de análisis para la creación de un nuevo enlace - Detección de abuso/estafa/phishing - Calentamiento de caché - Indexación de búsqueda - Pipeline de notificación/auditoría La ruta crítica solo debe incluir lo necesario para crear el mapeo y devolver la URL acortada. 5. Modelo de consistencia Para la respuesta de creación, usar consistencia post-creación para el nuevo código corto: - Una vez que la API devuelve éxito, la redirección debería funcionar de inmediato. Cómo: - Persistir el mapeo a un quórum/líder en la DB principal antes de acusar recibo. - Opcionalmente, escritura directa a Redis después de la confirmación de la DB. - La ruta de redirección recurre a la DB en caso de fallo de caché, por lo que el retraso en la propagación de la caché no rompe la corrección. 6. Idempotencia Admitir claves de idempotencia para clientes API para evitar enlaces duplicados durante reintentos. - Almacenar `request_id` -> `short_code` durante un TTL limitado en un almacén rápido. - Especialmente útil para escenarios de reintento móvil/de red. 7. Limitación de velocidad - Cuotas por usuario/clave API para controlar abusos. - Límites más estrictos en las solicitudes de alias personalizados. - Salvaguardias globales para prevenir la amplificación de escritura inducida por ataques. E. Confiabilidad y Tolerancia a Fallos 1. Objetivo de disponibilidad: 99.9% El 99.9% de tiempo de actividad permite aproximadamente 43.8 minutos de inactividad/mes. Esto es factible con despliegue multi-AZ y conmutación por error regional. 2. Manejo de fallos Fallo de nodo: - Nodos de aplicación sin estado detrás de balanceadores de carga; reemplazo automático de instancias no saludables. - Las cachés locales son desechables. - Redis desplegado como clúster/modo centinela de alta disponibilidad. Fallo de AZ: - Nivel de aplicación desplegado en al menos 3 AZ. - DB principal replicada entre AZ. - El balanceador de carga elimina la AZ no saludable. Fallo regional/DC: - Servicio de lectura activo-activo entre múltiples regiones. - Datos replicados entre regiones de forma asíncrona o casi síncrona según las capacidades de la DB. - El gestor de DNS/tráfico conmuta los usuarios a la región saludable. 3. Durabilidad de los datos - Factor de replicación de la DB principal 3 entre AZ. - Instantáneas/copias de seguridad periódicas en almacenamiento de objetos. - Archivado WAL/registro de confirmación si se admite. - Copias de seguridad entre regiones para recuperación ante desastres. 4. Estrategia de copia de seguridad y recuperación - Instantáneas completas diarias más copias de seguridad incrementales. - Recuperación a un punto en el tiempo para borrado/corrupción accidental. - Simulacros de restauración regulares en staging para verificar RTO/RPO. - Retención de copias de seguridad alineada con el requisito de accesibilidad de 5 años y necesidades de cumplimiento. Objetivos razonables: - RPO: minutos a 1 hora dependiendo del modelo de replicación entre regiones - RTO: menos de 1 hora para conmutación por error regional, más tiempo para reconstrucción completa del almacenamiento, pero eso debería ser raro 5. Estrategia de invalidación de caché Si los enlaces son en su mayoría inmutables, el almacenamiento en caché es simple. Para enlaces mutables (deshabilitar/cambiar destino/caducidad): - Actualizar la DB primero. - Publicar evento de invalidación. - Evictar clave de Redis y entradas de caché local. - Purgar la caché de CDN si se utiliza caché de borde para ese código. - Usar TTL limitado para que la caché obsoleta se autocorriga incluso si la invalidación falla. 6. Protección contra corrupción de datos y abusos - Restricciones de unicidad de DB en `short_code`. - Sumas de verificación/campos de versión para registros. - Registros de auditoría para acciones administrativas. - Estado de borrado suave o deshabilitado en lugar de borrado duro siempre que sea posible. - Herramientas de escaneo y desmantelamiento de malware/phishing. F. Compensaciones clave 1. Generación de ID determinista vs códigos cortos aleatorios Opciones: - ID deterministas secuenciales/basados en rangos: simples, sin colisiones, compactos, rápidos. - Códigos aleatorios: menos predecibles/enumerables pero requieren verificación de colisiones y más complejidad. Elección: - Elijo ID deterministas codificados en Base62. Por qué: - Más simple, más rápido y operacionalmente más seguro para esta escala. - Sin colisiones sin bucles de reintento. - Mejor ajuste porque el rendimiento es modesto y el principal desafío es la latencia de lectura. Costo: - Los códigos pueden ser más enumerables/predecibles. Mitigación: - Limitación de velocidad, detección de bots, alias opcionales más largos/no secuenciales para enlaces sensibles. 2. Consistencia más fuerte en la creación vs consistencia eventual en todas partes Opciones: - La consistencia eventual podría reducir la latencia de escritura y simplificar las escrituras multiregión. - El reconocimiento fuerte después de la escritura duradera garantiza que un código corto devuelto funcione de inmediato. Elección: - Consistencia fuerte para la ruta de creación de un solo enlace dentro de una región de origen; consistencia eventual para cachés secundarias y propagación entre regiones. Por qué: - Mejor experiencia de usuario: una vez que la API devuelve, la redirección debería tener éxito. - El volumen de escritura es lo suficientemente bajo como para no necesitar relajar la consistencia en la escritura crítica. 3. Almacenamiento en caché agresivo en el borde vs invalidación rápida Opciones: - TTL largos de CDN maximizan el rendimiento de lectura y reducen el costo de origen. - TTL cortos hacen que las operaciones de deshabilitación/actualización se propaguen más rápido. Elección: - TTL moderado con purga explícita para enlaces mutables/gestionados por administrador; TTL más largo para enlaces inmutables. Por qué: - La mayoría de las URL acortadas son efectivamente inmutables, por lo que el almacenamiento en caché proporciona importantes beneficios de latencia y costo. - Pero las deshabilitaciones por abuso requieren una invalidación razonablemente rápida. 4. Simplicidad vs riqueza de análisis en la ruta de redirección Opciones: - El registro de clics síncrono proporciona garantías de análisis inmediatas pero agrega latencia y acoplamiento de fallos. - La emisión asíncrona de eventos mantiene las redirecciones rápidas, pero los análisis pueden retrasarse o perderse pequeñas cantidades durante los fallos. Elección: - Análisis asíncrono. Por qué: - El SLA estricto del producto es la latencia y disponibilidad de redirección, no los análisis en tiempo real sin pérdidas. - La ruta de redirección nunca debe bloquearse en los sistemas de registro posteriores. Resumen de la arquitectura - Generación de códigos cortos: ID únicos de 64 bits basados en rangos alquilados o estilo Snowflake codificados en Base62, códigos estándar de 7 caracteres. - Almacén principal: base de datos KV distribuida, particionada por hash en `short_code`, RF=3, multi-AZ. - Ruta de lectura: CDN + caché local + Redis + fallback a KV store; lecturas activo-activo multiregión. - Ruta de escritura: API sin estado + escritura en DB duradera + cola asíncrona para efectos secundarios; idempotencia y límites de velocidad. - Confiabilidad: multi-AZ, replicación entre regiones, copias de seguridad, eventos de invalidación de caché, conmutación por error de DNS. - Este diseño admite cómodamente 100M de URL nuevas/mes, relación de lectura 100:1, retención de 5 años, 99.9% de tiempo de actividad y redirecciones <50 ms p95.

## Diseño de un Servicio de Acortamiento de URL Este documento describe el diseño de un servicio de acortamiento de URL capaz de manejar 100 millones de URL nuevas por mes, una relación de lectura/escritura de 100:1, retención de datos de 5 años, un tiempo de actividad del 99.9% y una latencia de redirección inferior a 50 ms en el percentil 95. ### A. Estrategia de Generación de URL Cortas **Esquema de Codificación**: Utilizaremos la codificación Base62 (0-9, a-z, A-Z). Este esquema es seguro para URL y proporciona una representación compacta para identificadores únicos. **Longitud Esperada de URL**: Durante 5 años, el servicio necesita soportar 100 millones de URL/mes * 12 meses/año * 5 años = 6 mil millones de URL únicas. Una cadena Base62 de 6 caracteres proporciona 62^6 = 56,800,235,584 claves únicas posibles, lo cual es más que suficiente para 6 mil millones de URL. Comenzaremos con 6 caracteres y tendremos la flexibilidad de extender a 7 caracteres (62^7 ≈ 352 mil millones de claves) si el espacio de claves se agota alguna vez. **Método de Generación**: Emplearemos un **Servicio de Generación de Claves (KGS)**. Este servicio será responsable de generar identificadores numéricos únicos y monotónicamente crecientes. Estos identificadores se codificarán luego en Base62 para producir los códigos de URL cortos. El KGS puede utilizar un algoritmo de generación de ID distribuido (por ejemplo, un generador de ID Snowflake modificado o un servicio dedicado que incrementa un contador y preasigna bloques de ID a múltiples instancias de KGS para evitar la contención). Este enfoque garantiza la unicidad y evita colisiones por diseño, eliminando la necesidad de búsquedas en la base de datos durante la generación de claves. **Manejo de Colisiones**: Con el KGS generando identificadores numéricos únicos, las colisiones se evitan inherentemente. Cada ID generado es único, y su codificación Base62 también será única. Si se eligiera una estrategia de generación aleatoria, el manejo de colisiones implicaría verificar la existencia en la base de datos y regenerar en caso de colisión, lo que añade latencia y complejidad. **Agotamiento del Espacio de Claves**: Como se discutió, una clave Base62 de 6 caracteres proporciona un amplio espacio para 6 mil millones de URL. Si el servicio creciera más allá de esto, extender la longitud de la clave a 7 caracteres proporcionaría una capacidad significativamente mayor. El KGS estaría diseñado para manejar esta transición sin problemas generando ID más largos cuando sea necesario. ### B. Almacenamiento de Datos **Selección de Base de Datos**: Para la asignación principal de `short_code` a `long_url`, utilizaremos un **almacén distribuido de clave-valor NoSQL** como **Apache Cassandra**. Cassandra es altamente escalable, tolerante a fallos y optimizado para lecturas y escrituras de alto volumen y baja latencia, lo que lo hace ideal para nuestra carga de trabajo con muchas lecturas. Su naturaleza distribuida y sus capacidades de replicación integradas garantizan alta disponibilidad y durabilidad de los datos. **Estimación de Almacenamiento**: * URL totales durante 5 años: 6 mil millones. * Cada entrada almacenará: * `short_code`: 6-7 caracteres (aprox. 7 bytes) * `long_url`: Promedio de 100 caracteres (aprox. 100 bytes) * `created_at`: Marca de tiempo (8 bytes) * `expires_at`: Marca de tiempo (8 bytes, para retención de 5 años) * `click_count`: Contador (8 bytes) * `user_id` (opcional): por ejemplo, 36 bytes para UUID * Total por entrada (estimación conservadora, incluyendo sobrecarga): ~150 bytes. * Almacenamiento bruto total: 6 mil millones de URL * 150 bytes/URL = 900 mil millones de bytes = 0.9 TB. * Con un factor de replicación de 3 (común para Cassandra para alta disponibilidad): 0.9 TB * 3 = **2.7 TB**. **Diseño del Esquema (Cassandra)**: ```sql CREATE TABLE short_urls ( short_code text PRIMARY KEY, -- Clave de partición para distribución uniforme long_url text, created_at timestamp, expires_at timestamp, click_count counter, user_id text ); ``` **Estrategia de Particionamiento/Fragmentación**: Cassandra maneja inherentemente el particionamiento y la fragmentación de datos basándose en la clave primaria (`short_code`). El `short_code` Base62 proporciona una buena distribución de datos entre los nodos del clúster, evitando puntos calientes y garantizando una recuperación de datos eficiente. ### C. Arquitectura de la Ruta de Lectura **Rendimiento**: Con 100 millones de escrituras/mes y una relación de lectura/escritura de 100:1, esperamos 10 mil millones de lecturas/mes, lo que promedia aproximadamente 3,858 lecturas/segundo. Las cargas pico podrían ser 5-10 veces mayores, alcanzando 20,000-40,000 lecturas/segundo. **Componentes de la Arquitectura**: 1. **Balanceador de Carga (por ejemplo, AWS ELB, Nginx)**: Distribuye las solicitudes HTTP entrantes para URL cortas entre múltiples instancias del Servicio de Redirección. 2. **Caché Distribuida (por ejemplo, Clúster Redis)**: Esto es fundamental para cumplir con los requisitos de latencia y rendimiento. La caché almacenará las asignaciones de `short_code` a `long_url`. Dada la relación de lectura/escritura de 100:1, se espera una tasa de aciertos de caché muy alta (por ejemplo, más del 95%), lo que reduce significativamente la carga en la base de datos. * **Invalidación de Caché**: Las asignaciones de URL cortas son generalmente inmutables. Las entradas de caché pueden tener un TTL muy largo o ser permanentes. Si alguna vez se necesita actualizar una `long_url` (raro), se activaría una invalidación explícita de la caché. 3. **Servicio de Redirección (Servidores de Aplicaciones)**: Una flota de servidores de aplicaciones sin estado (por ejemplo, ejecutando Go, Java o Node.js) detrás del balanceador de carga. * Al recibir una solicitud de URL corta, el servicio primero verifica la caché de Redis. * Si hay un acierto de caché, emite inmediatamente una redirección HTTP 301 (Permanente) o 302 (Temporal) a la `long_url`. * Si no hay acierto de caché, consulta la base de datos Cassandra para obtener el `short_code`. * Una vez recuperada de Cassandra, la asignación se almacena en Redis para futuras solicitudes, y luego se emite la redirección. * Los recuentos de clics se actualizan de forma asíncrona (por ejemplo, enviando mensajes a una cola de Kafka para su procesamiento por un servicio de análisis separado o incrementando un contador directamente en Cassandra, que admite incrementos atómicos). 4. **Base de Datos (Clúster Cassandra)**: Sirve como almacenamiento persistente para todas las asignaciones de URL y maneja los fallos de caché. Su naturaleza distribuida y replicación garantizan alta disponibilidad y recuperación de datos de baja latencia para la escala requerida. **Estrategias de Replicación**: * **Servidores de Aplicaciones**: Múltiples instancias implementadas en diferentes zonas de disponibilidad, gestionadas por grupos de autoescalado. * **Caché**: Clúster Redis con configuraciones maestro-réplica para cada fragmento, garantizando alta disponibilidad y redundancia de datos. * **Base de Datos**: La replicación nativa de Cassandra en múltiples centros de datos (por ejemplo, factor de replicación 3x en al menos dos centros de datos) proporciona una sólida tolerancia a fallos y capacidades de recuperación ante desastres. ### D. Arquitectura de la Ruta de Escritura **Rendimiento**: 100 millones de URL nuevas por mes se traducen en un promedio de ~38 escrituras/segundo. Las cargas pico podrían alcanzar 300-400 escrituras/segundo. **Componentes de la Arquitectura**: 1. **Balanceador de Carga**: Distribuye las solicitudes entrantes para acortar URL a las instancias del Servicio de Escritura. 2. **Servicio de Escritura (API Gateway/Servidores de Aplicaciones)**: * Recibe la `long_url` del usuario. * Llama al **Servicio de Generación de Claves (KGS)** para obtener un `short_code` único. * Construye la asignación de `short_code` a `long_url`. * Publica esta asignación en una **Cola de Mensajes (por ejemplo, Apache Kafka)**. Esto desacopla el servicio de escritura de la base de datos, proporciona almacenamiento en búfer y mejora la fiabilidad. * Devuelve el `short_code` generado al usuario. 3. **Servicio de Generación de Claves (KGS)**: Como se describe en la Sección A, este servicio genera ID numéricos únicos y los codifica en `short_code`s Base62. Puede pregenerar bloques de claves para minimizar la latencia durante los picos de escritura. 4. **Procesos Trabajadores (Consumidores)**: Un grupo de procesos trabajadores consume mensajes de la cola de Kafka. * Para cada mensaje, el trabajador escribe el `short_code` y la `long_url` en la **base de datos Cassandra**. * Luego escribe inmediatamente la asignación en la **Caché Redis** para garantizar que la URL corta recién creada esté disponible instantáneamente para lecturas. 5. **Base de Datos (Clúster Cassandra)**: Almacena de forma persistente las nuevas asignaciones de URL. **Consideraciones de Consistencia**: * Para la asignación de `short_code` a `long_url`, se desea una fuerte consistencia. Al escribir en Cassandra con niveles de consistencia apropiados (por ejemplo, `QUORUM`) y luego poblar inmediatamente la caché, nos aseguramos de que una vez que un código corto se devuelve al usuario, se resolverá correctamente. * El uso de una cola de mensajes proporciona consistencia eventual para la capa de persistencia, pero la actualización inmediata de la caché garantiza que la ruta de lectura sea consistente para las URL nuevas. Si la actualización de la caché falla, la ruta de lectura eventualmente llegará a la base de datos, que será consistente. ### E. Fiabilidad y Tolerancia a Fallos **Fallos de Nodos**: * **Servidores de Aplicaciones (Servicios de Redirección y Escritura)**: Sin estado y desplegados en grupos de autoescalado en múltiples zonas de disponibilidad. Los balanceadores de carga enrutan automáticamente el tráfico lejos de las instancias fallidas, y se lanzan nuevas instancias para reemplazarlas. * **Caché Distribuida (Clúster Redis)**: Configurado con replicación maestro-réplica. Si falla un nodo maestro, una réplica es promovida automáticamente a maestro, minimizando el tiempo de inactividad y la pérdida de datos para los elementos cacheados. * **Base de Datos (Clúster Cassandra)**: Diseñado para alta disponibilidad con un factor de replicación de 3 en múltiples nodos y centros de datos. Si falla un nodo, sus datos están disponibles en otras réplicas, y Cassandra maneja automáticamente la reparación de datos y el reemplazo del nodo fallido. * **Servicio de Generación de Claves (KGS)**: Desplegado con múltiples instancias detrás de un balanceador de carga. El mecanismo subyacente de generación de ID distribuido (por ejemplo, usando Zookeeper para coordinación o un contador altamente disponible) garantiza que se puedan generar ID únicos incluso si fallan algunas instancias de KGS. * **Cola de Mensajes (Kafka)**: Desplegado como un clúster con replicación. Si falla un broker, otros brokers continúan operando y los datos se replican para garantizar que no se pierdan mensajes. **Interrupciones de Centros de Datos**: Todo el sistema se desplegará en al menos dos centros de datos geográficamente distintos o múltiples zonas de disponibilidad dentro de una región. Los balanceadores de carga se configurarán para failover entre zonas/regiones. La replicación de Cassandra en múltiples centros de datos garantiza la durabilidad y disponibilidad de los datos, incluso si un centro de datos completo deja de estar disponible. **Invalidación de Caché**: Dado que las asignaciones de `short_code` a `long_url` son en gran medida inmutables, la invalidación explícita de caché rara vez es necesaria. Las entradas de caché pueden tener un TTL muy largo. Si alguna vez se necesita actualizar una `long_url` (por ejemplo, por razones legales), el servicio de escritura actualizaría la base de datos y luego invalidaría/actualizaría explícitamente la entrada correspondiente en la caché de Redis. **Estrategia de Copia de Seguridad y Recuperación**: * **Base de Datos**: Se tomarán instantáneas automatizadas y regulares de los datos del clúster Cassandra y se almacenarán en un servicio de almacenamiento de objetos altamente duradero (por ejemplo, AWS S3, Google Cloud Storage). Estas copias de seguridad permiten la recuperación en un punto en el tiempo en caso de corrupción de datos o eliminación accidental. Las copias de seguridad incrementales y los registros de confirmación de Cassandra también se pueden utilizar para una recuperación más granular. * **Configuración**: Toda la infraestructura (Infraestructura como Código) y las configuraciones de aplicaciones se controlarán en versiones (por ejemplo, Git) y se desplegarán utilizando canalizaciones automatizadas, lo que permitirá una restauración rápida de las configuraciones del servicio. * **Monitorización y Alertas**: Se implementará una monitorización integral (por ejemplo, Prometheus, Grafana) para rastrear la salud del sistema, las métricas de rendimiento y las tasas de error. Las alertas automatizadas notificarán a los equipos de operaciones de cualquier anomalía o fallo, permitiendo una respuesta y recuperación rápidas. ### F. Compensaciones Clave 1. **Consistencia vs. Disponibilidad (para la asignación de `short_code` a `long_url`)** * **Compensación Elegida**: Priorizamos la fuerte consistencia para la asignación principal de `short_code` a `long_url`, al tiempo que permitimos la consistencia eventual para datos auxiliares como los recuentos de clics. * **Explicación**: El propósito fundamental de un acortador de URL es redirigir de manera confiable una URL corta a su URL larga correcta. Una asignación inconsistente (por ejemplo, redirigir a la URL incorrecta o no redirigir) degradaría severamente la experiencia del usuario y rompería el contrato central del servicio. Por lo tanto, nos aseguramos de que una vez que se crea un `short_code` y se devuelve al usuario, se resuelva inmediatamente a la `long_url` correcta. Esto se logra escribiendo en Cassandra con niveles de consistencia fuertes (por ejemplo, `QUORUM`) y poblando inmediatamente la caché de Redis. La disponibilidad se mantiene a través de una extensa replicación y una arquitectura distribuida, lo que garantiza que el servicio permanezca operativo incluso con requisitos de fuerte consistencia para la ruta crítica. Los recuentos de clics, sin embargo, pueden tolerar ligeros retrasos en las actualizaciones, lo que hace que la consistencia eventual sea aceptable para estos datos no críticos. 2. **Simplicidad vs. Escalabilidad/Rendimiento (Estrategia de Generación de Claves)** * **Compensación Elegida**: Optamos por un Servicio de Generación de Claves (KGS) dedicado que utiliza un contador distribuido y codificación Base62, que es más complejo, en lugar de un enfoque más simple de generar cadenas Base62 aleatorias y verificar colisiones. * **Explicación**: Si bien generar cadenas aleatorias y verificar colisiones en la base de datos es más simple de implementar inicialmente, introduce varios desafíos de escalabilidad y rendimiento. A medida que el espacio de claves se llena, la probabilidad de colisiones aumenta, lo que lleva a más reintentos y mayor latencia en la ruta de escritura. Este patrón de leer antes de escribir puede convertirse en un cuello de botella bajo cargas de escritura altas. El enfoque KGS elegido, aunque más complejo de diseñar y mantener (requiere un generador de ID distribuido), garantiza claves únicas sin colisiones. Permite la pregeneración de bloques de claves, lo que reduce significativamente la latencia de adquisición de claves para el servicio de escritura. Esta complejidad inicial se justifica por la necesidad de una generación de claves predecible, de alto rendimiento y altamente escalable durante la vida útil de 5 años del servicio, lo que garantiza que la ruta de escritura siga siendo eficiente y confiable a medida que el sistema crece.