Diseñar un servicio global de acortamiento de URLs

### 1. Arquitectura de Alto Nivel El sistema está diseñado como un servicio globalmente distribuido y multirregión para garantizar baja latencia y alta disponibilidad. Cada región principal (por ejemplo, US-East, EU-West, AP-Southeast) alberga un Punto de Presencia (PoP) completo. **Componentes:** 1. **Balanceador de Carga Global (GLB):** Utiliza enrutamiento DNS basado en latencia para dirigir a los usuarios al PoP regional saludable más cercano. 2. **Pila de PoP Regional:** * **API Gateway:** Termina TLS, autentica solicitudes y las enruta al servicio backend apropiado. * **Servicio de Redirección:** Un servicio ligero y altamente escalado que maneja las solicitudes `GET /{alias_corto}`. Está optimizado para la velocidad. * **Servicio de Escritura:** Maneja la creación de enlaces (`POST /api/v1/links`), incluyendo la validación de alias personalizados y la generación de IDs únicos. * **Servicio de Analíticas:** Proporciona acceso a las estadísticas de enlaces a través de `GET /api/v1/links/{alias_corto}/stats`. 3. **Infraestructura de Datos:** * **Base de Datos Global:** Una base de datos distribuida y fuertemente consistente para el mapeo principal de enlaces. * **Caché Regional:** Una caché en memoria en cada región para enlaces populares. * **Pipeline de Analíticas:** Una cola de mensajes para la ingesta de eventos, un procesador de flujos para la agregación y una base de datos NoSQL para almacenar y servir datos de analíticas. **Flujo de Datos:** * **Creación de Enlace:** La solicitud `POST` de un usuario se enruta al Servicio de Escritura más cercano. El servicio genera o valida un alias y escribe el mapeo `alias_corto -> URL_larga` en la Base de Datos Global. La escritura se replica sincrónicamente en todas las regiones en menos de 2 segundos. * **Redirección:** Una solicitud `GET` se enruta al Servicio de Redirección más cercano. Primero verifica la Caché Regional. En caso de acierto en la caché, emite inmediatamente una redirección 301 y envía asincrónicamente un evento de clic a la cola de analíticas. En caso de fallo, consulta la réplica local de la Base de Datos Global, popula la caché, luego realiza la redirección y el registro de eventos. * **Analíticas:** Los eventos de clic de todas las regiones se publican en una cola de mensajes central. Un procesador de flujos consume estos eventos, los agrega en estadísticas de ventanas de tiempo (clics totales, clics en 24h, recuentos por país) y escribe los resultados en la Base de Datos de Analíticas. ### 2. Opciones de Almacenamiento * **Mapeos de Enlaces (Almacenamiento Principal):** * **Tecnología:** Una base de datos SQL distribuida globalmente como Google Cloud Spanner o CockroachDB. * **Justificación:** Esta elección está impulsada por la necesidad de consistencia fuerte en las redirecciones y el requisito de propagación global de escrituras de <2 segundos. Estas bases de datos proporcionan replicación síncrona y lecturas regionales de baja latencia, justificando su mayor costo para la función comercial principal. El `alias_corto` sirve como clave primaria para búsquedas rápidas. * **Enlaces Populares en Caché:** * **Tecnología:** Una caché distribuida en memoria regional como Redis Cluster. * **Justificación:** Con 8 mil millones de lecturas diarias y un tráfico muy sesgado, una caché es esencial para cumplir el objetivo de latencia P95 de <80ms y proteger la base de datos. Cada región mantiene su propia caché utilizando un patrón de caché-aside. * **Datos de Analíticas:** * **Cola de Ingesta:** Apache Kafka o AWS Kinesis. Esto desacopla la ruta de redirección de alto rendimiento del procesamiento de analíticas y proporciona un búfer duradero para los eventos de clic. * **Base de Datos de Servicio:** Un almacén NoSQL de columnas anchas como Apache Cassandra o ScyllaDB. Está optimizado para la carga de trabajo de agregación de series temporales y alta escritura de analíticas, y es más rentable a escala para estos patrones de consulta que una base de datos relacional. ### 3. Generación de IDs y Estrategia de Alias Usaremos un alias de 7 caracteres del alfabeto `[a-zA-Z0-9]`, proporcionando `62^7` (más de 3.5 billones) combinaciones únicas. * **Generación de IDs:** Un servicio en segundo plano pregenera un gran grupo de IDs únicos y los almacena en una cola dedicada (por ejemplo, una lista de Redis). El Servicio de Escritura simplemente obtiene un ID pregenerado de este grupo cuando se crea un nuevo enlace. Este enfoque es rápido, escalable y evita comprobaciones de colisión sobre la marcha durante una solicitud del usuario. * **Manejo de Alias Personalizados:** Cuando un usuario envía un alias personalizado, el Servicio de Escritura intenta `INSERT`arlo en la Base de Datos Global. La columna `alias_corto` es la clave primaria con una restricción única. Esto maneja atómicamente la operación de verificación y establecimiento; si el alias ya está en uso, la base de datos rechaza la escritura y el servicio devuelve un error `409 Conflict` al usuario. ### 4. Diseño de la API * **Crear Enlace:** `POST /api/v1/links` * **Cuerpo:** `{ "long_url": "...", "custom_alias": "..." (opcional), "expires_at": "..." (opcional) }` * **Respuesta:** `201 Created` con `{ "short_url": "...", "long_url": "..." }` * **Redireccionar:** `GET /{alias_corto}` * **Respuesta:** `301 Moved Permanently` con encabezado `Location: {long_url}` para enlaces permanentes. `404 Not Found` si el alias no existe o ha expirado. * **Obtener Analíticas:** `GET /api/v1/links/{alias_corto}/stats` * **Respuesta:** `200 OK` con `{ "total_clicks": ..., "clicks_last_24h": ..., "top_countries": [...] }` ### 5. Enfoque de Escalado * **Claves Populares:** Se emplea una estrategia de caché de múltiples capas. Para enlaces extremadamente virales, la respuesta de redirección `301` se puede almacenar en caché en la capa CDN. La defensa principal es la caché regional de Redis, que absorberá la mayor parte del tráfico sesgado. * **Particionamiento:** La Base de Datos Global (Spanner/CockroachDB) maneja automáticamente el particionamiento de los datos de enlaces por su clave primaria (`alias_corto`). La Base de Datos de Analíticas (Cassandra) se particionará por `alias_corto` para co-ubicar todas las estadísticas de un enlace determinado, permitiendo consultas eficientes. * **Tráfico Multirregión:** El GLB garantiza que los usuarios sean dirigidos a su PoP más cercano para una baja latencia. La arquitectura es activa-activa, ya que las escrituras pueden ser manejadas por cualquier región y son replicadas globalmente por la base de datos. Este diseño maximiza la utilización de recursos y la disponibilidad. ### 6. Estrategia de Fiabilidad * **Failover:** El GLB realiza comprobaciones de estado y dirigirá automáticamente el tráfico lejos de cualquier región no saludable. Dentro de una región, los balanceadores de carga dirigirán el tráfico alrededor de las instancias de servicio fallidas. * **Replicación de Datos:** La Base de Datos Global está configurada para replicar datos a través de múltiples zonas de disponibilidad y regiones, proporcionando resiliencia contra fallos tanto de instancias como de regiones. El clúster de Cassandra para analíticas también se desplegará en múltiples regiones. * **Copia de Seguridad:** Se toman instantáneas automatizadas y periódicas de las bases de datos primaria y de analíticas y se almacenan en almacenamiento de objetos duradero (por ejemplo, AWS S3) para la recuperación ante desastres. * **Degradación Elegante:** El sistema está diseñado de manera que un fallo en el pipeline de analíticas no crítico no afectará la funcionalidad principal de redirección. El Servicio de Redirección continuará sirviendo solicitudes incluso si no puede publicar eventos en la cola de mensajes. ### 7. Compromisos y Alternativas Rechazadas * **Alternativa 1: Generación de IDs basada en Hash (Rechazada). * **Concepto:** Generar un ID corto hasheando la URL larga. Si ocurre una colisión, añadir una sal y volver a hashear. * **Razón del Rechazo:** Esto añade latencia e impredecibilidad al camino de escritura. Con 120 millones de escrituras por día, la probabilidad de colisión se vuelve significativa, requiriendo múltiples búsquedas en la base de datos para encontrar un ID único. La estrategia de pregeneración elegida proporciona un rendimiento de tiempo constante para la adquisición de IDs durante una solicitud del usuario. * **Alternativa 2: Base de Datos Relacional de Maestro Único (Rechazada). * **Concepto:** Usar una base de datos tradicional como PostgreSQL en una región principal única con réplicas de lectura en otras regiones. * **Razón del Rechazo:** Este diseño no puede cumplir el estricto requisito de propagación global de escrituras de `<2 segundos`. El retraso de replicación a réplicas de lectura distantes excedería frecuentemente este umbral, lo que significaría que un enlace recién creado no estaría inmediatamente disponible para todos los usuarios globales. El mayor costo de una base de datos distribuida globalmente se justifica para cumplir este requisito funcional principal.

SERVICIO GLOBAL DE ACORTAMIENTO DE URL — DISEÑO DEL SISTEMA ───────────────────────────────────────── 1. ARQUITECTURA DE ALTO NIVEL Y FLUJO DE DATOS ───────────────────────────────────────── El sistema se organiza en tres planos: el Camino de Escritura (creación de enlaces), el Camino de Lectura (redirección) y el Camino de Analítica (ingesta y consulta de eventos). Componentes principales: - Balanceador de Carga Global Anycast / Borde de CDN (p. ej., Cloudflare o AWS CloudFront con Lambda@Edge) - Pasarela API + Capa de Autenticación (limitación de tasa, prevención de abusos) - Servicio de Creación de Enlaces (sin estado, escalable horizontalmente) - Servicio de Redirección (sin estado, extremadamente sensible a la latencia) - Servicio de Generación de IDs (productor distribuido de códigos cortos únicos) - Almacén de Enlaces Primario (base de datos relacional replicada globalmente, p. ej., CockroachDB o AWS Aurora Global) - Caché de Enlaces Populares (Redis Cluster, por región) - Cola de Ingesta de Analítica (Kafka o AWS Kinesis, por región) - Trabajadores de Agregación de Analítica (procesadores de flujo, p. ej., Flink o Kafka Streams) - Almacén de Analítica (almacén columnar, p. ej., ClickHouse o Apache Druid) - Servicio de Consulta de Analítica (API de solo lectura) - Almacenamiento de Objetos para copias de seguridad en frío (compatible con S3) Camino de Escritura (creación de enlaces): 1. El cliente envía una solicitud POST a la Pasarela API regional más cercana. 2. La Pasarela API autentica y limita la tasa de la solicitud, luego la reenvía al Servicio de Creación de Enlaces. 3. El Servicio de Creación de Enlaces llama al Servicio de Generación de IDs para obtener un código corto único (o valida un alias personalizado). 4. El registro se escribe en el Almacén de Enlaces Primario con fuerte consistencia en la región local; la replicación global de la base de datos propaga el registro a otras regiones en ~1–2 segundos, cumpliendo el SLA de "utilizable en 2 segundos a nivel mundial". 5. Simultáneamente, la nueva asignación se envía a la caché Redis regional (escritura directa o invalidación pub/sub) para que la primera redirección en esa región no falle en la caché. 6. Se devuelve una respuesta 201 con la URL corta al cliente. Camino de Lectura (redirección): 1. El cliente emite GET /{codigoCorto} al nodo de borde más cercano. 2. El nodo de borde verifica su propia caché de CDN (para enlaces extremadamente populares, TTL ~5–10 segundos para respetar la semántica de expiración). 3. En caso de fallo en la caché de CDN, la solicitud llega al Servicio de Redirección regional. 4. El Servicio de Redirección verifica la caché Redis regional (tasa de aciertos esperada > 99% para enlaces populares). 5. En caso de fallo en Redis, el Servicio de Redirección consulta la réplica de lectura local del Almacén de Enlaces Primario. 6. Si el enlace ha expirado o no se encuentra, devuelve 404/410. 7. De lo contrario, emite una redirección HTTP 301 (permanente) o 302 (temporal). Usa 302 por defecto para que los navegadores no cacen indefinidamente, preservando la precisión de la analítica. 8. Emite asincrónicamente un evento de clic (codigoCorto, timestamp, país derivado de IP, user-agent) a la Cola de Ingesta de Analítica regional. Esto es "disparar y olvidar"; no bloquea la respuesta de redirección. Camino de Analítica: 1. Los temas de Kafka regionales reciben eventos de clic. 2. Los trabajos de Flink/Kafka Streams consumen eventos y mantienen agregados rodantes: clics totales (contador), clics en las últimas 24 horas (ventana deslizante) y los 5 principales países (esquema aproximado de los más frecuentes, p. ej., Count-Min Sketch o SpaceSaving). 3. Los resultados agregados se escriben en ClickHouse (almacén columnar optimizado para anexos) cada 30–60 segundos. 4. El Servicio de Consulta de Analítica lee de ClickHouse y devuelve resultados pre-agregados. Los eventos brutos también se conservan en ClickHouse para consultas ad hoc. 5. Agregación de analítica entre regiones: el clúster de Kafka de cada región refleja eventos a una región de analítica central a través de Kafka MirrorMaker 2 o replicación entre regiones de Kinesis. El clúster central de ClickHouse contiene la vista global. ───────────────────────────────────────── 2. OPCIONES DE ALMACENAMIENTO ───────────────────────────────────────── Mapeos de Enlaces — CockroachDB (o Aurora Global DB): Justificación: Necesitamos fuerte consistencia para las escrituras (para prevenir alias duplicados) y lecturas de baja latencia a nivel mundial. CockroachDB es una base de datos SQL distribuida con soporte activo-activo multiregión, aislamiento serializable y failover automático. Aurora Global DB es una alternativa con un escritor primario único y hasta 5 réplicas de lectura en diferentes regiones con un retraso de replicación de ~1 s. Cualquiera de las dos satisface el SLA de propagación global de 2 segundos. Esquema (simplificado): links(short_code VARCHAR(12) PK, long_url TEXT NOT NULL, owner_id BIGINT, created_at TIMESTAMPTZ, expires_at TIMESTAMPTZ, is_custom BOOLEAN) Índices: short_code (PK, agrupado), owner_id + created_at (para paneles de usuario). Tamaño estimado: 120M enlaces/día × 365 días × ~300 bytes/fila ≈ ~13 TB/año. Manejable con partición por created_at. Caché de Enlaces Populares — Redis Cluster (por región): Cada región ejecuta un Redis Cluster con 3–6 shards y réplicas. Entradas de caché: short_code → {long_url, expires_at}. TTL establecido en min(expiración del enlace, 24 horas). Conjunto de trabajo esperado: el 1% superior de los enlaces (~1.2M) representa ~80% del tráfico. Con ~500 bytes por entrada, 1.2M de entradas ≈ 600 MB por región — muy asequible. Usamos una estrategia de escritura directa en la creación de enlaces y población perezosa en el primer fallo de redirección. Eventos de Analítica — Kafka + ClickHouse: Kafka retiene eventos de clic brutos durante 7 días (reproducibilidad). ClickHouse almacena tanto eventos brutos (particionados por fecha, shardeados por short_code) como vistas materializadas pre-agregadas. El almacenamiento columnar y la ejecución vectorizada de ClickHouse lo hacen ideal para las consultas de agregación necesarias (SUM, COUNT, GROUP BY país, ventana deslizante). Copias de Seguridad en Frío — Almacenamiento de objetos compatible con S3: Instantáneas diarias del almacén de enlaces y exportaciones semanales de ClickHouse se almacenan en almacenamiento de objetos con versionado y replicación entre regiones para recuperación ante desastres. ───────────────────────────────────────── 3. ESTRATEGIA DE GENERACIÓN DE IDs Y ALIAS ───────────────────────────────────────── Formato del Código Corto: Utiliza 7 caracteres de un alfabeto Base62 (a-z, A-Z, 0-9). Base62^7 = ~3.5 billones de combinaciones, superando con creces cualquier necesidad previsible (120M/día × 10 años = ~438 mil millones de enlaces). Estrategia de Generación de IDs — Contador Distribuido + Codificación: Usamos un enfoque de contador distribuido en lugar de generación aleatoria para evitar tormentas de colisiones a escala. Paso 1: Cada instancia del Servicio de Creación de Enlaces adquiere un bloque de IDs de un servicio de coordinación ligero (p. ej., un Redis INCRBY o un servicio de ID dedicado respaldado por ZooKeeper). Cada instancia reclama un bloque de 10,000 IDs a la vez, reduciendo la sobrecarga de coordinación. Paso 2: El ID numérico se codifica en Base62 para producir el código corto. Un código Base62 de 7 caracteres puede representar IDs de hasta ~3.5 billones. Paso 3: Para prevenir ataques de enumeración y añadir imprevisibilidad, haz XOR del ID numérico con una sal secreta antes de codificar, o usa una función de mezcla biyectiva (cifrado Feistel sobre el espacio de IDs). Alias Personalizados: 1. El cliente envía el alias deseado (3–20 caracteres alfanuméricos). 2. El Servicio de Creación de Enlaces intenta una INSERT con el alias personalizado como short_code usando una restricción de unicidad en la base de datos. 3. Si la INSERT falla debido a una violación de la restricción de unicidad, devuelve HTTP 409 Conflict con una sugerencia para probar otro alias. 4. Los alias personalizados omiten completamente el servicio de generación de IDs. 5. Los alias personalizados se reservan en una verificación de espacio de nombres separada (lista de groserías, palabras reservadas como "api", "admin", "health") antes de la escritura en la base de datos. Manejo de Colisiones para Códigos Generados: Dado que usamos un contador monótonamente creciente con codificación biyectiva, las colisiones son estructuralmente imposibles para los códigos generados. Las colisiones solo pueden ocurrir si un código generado coincide accidentalmente con un alias personalizado; esto se maneja mediante la restricción de unicidad; el servicio de generación de IDs simplemente incrementa al siguiente ID y reintenta (extremadamente raro). ───────────────────────────────────────── 4. DISEÑO DE API ───────────────────────────────────────── Todas las API son RESTful sobre HTTPS. La limitación de tasa se aplica en la capa de Pasarela API (p. ej., 100 creaciones/minuto por usuario autenticado, 10 creaciones/minuto para usuarios anónimos). POST /v1/links — Crear Enlace Corto Cuerpo de la solicitud (JSON): long_url: string (requerido, debe ser una URL válida, máx. 2048 caracteres) custom_alias: string (opcional, 3–20 caracteres alfanuméricos) expires_at: fecha y hora ISO 8601 (opcional) owner_id: string (opcional, del token de autenticación) Respuesta 201 Created: short_code: string short_url: string (p. ej., "https://sho.rt/aB3xY7z") long_url: string expires_at: string o null created_at: string Respuesta 400: URL o formato de alias inválido Respuesta 409: alias personalizado ya tomado Respuesta 429: límite de tasa excedido GET /{shortCode} — Redirección Sin cuerpo de solicitud. Parámetro de ruta: shortCode. Respuesta 302 Found con la cabecera Location establecida a long_url. Respuesta 404: código corto no encontrado. Respuesta 410 Gone: enlace ha expirado. Este endpoint se sirve en el dominio raíz (p. ej., sho.rt/{shortCode}) para una longitud mínima de URL. GET /v1/links/{shortCode}/analytics — Recuperar Analítica Autenticación requerida (propietario o administrador). Parámetros de consulta: ninguno requerido (devuelve resumen predeterminado) Respuesta 200: short_code: string total_clicks: entero clicks_last_24h: entero top_countries: matriz de objetos, cada uno con country_code (ISO 3166-1 alpha-2) y click_count, ordenado descendentemente, máx. 5 entradas last_updated: fecha y hora ISO 8601 (indica frescura de la analítica) Respuesta 404: enlace no encontrado. Respuesta 403: no autorizado. GET /v1/links/{shortCode} — Obtener Metadatos del Enlace (endpoint de utilidad opcional) Autenticación requerida. Respuesta 200: objeto de enlace completo incluyendo long_url, created_at, expires_at, is_custom. DELETE /v1/links/{shortCode} — Eliminar / Desactivar Enlace Autenticación requerida (propietario o administrador). Respuesta 204 No Content. Elimina lógicamente el registro (establece una marca de tiempo deleted_at) e invalida la entrada de caché a través de pub/sub. ───────────────────────────────────────── 5. ENFOQUE DE ESCALADO ───────────────────────────────────────── Problema de Clave Caliente: Una pequeña fracción de enlaces (URLs virales, campañas de marketing) recibirá millones de redirecciones por minuto. El sharding ingenuo de Redis pone todo el tráfico de una clave en un solo shard. Método de mitigación: - Caché local en memoria en cada instancia del Servicio de Redirección (p. ej., Caffeine con un LRU de 10,000 entradas, TTL de 5 segundos). Esto absorbe las claves más populares completamente dentro del proceso, eliminando los viajes de ida y vuelta a Redis para el 0.1% superior de los enlaces. - Caché de borde de CDN con un TTL corto (5–10 segundos) para la respuesta de redirección en sí. Con 8 mil millones de redirecciones/día, incluso una tasa de aciertos de CDN del 90% descarga 7.2 mil millones de solicitudes del origen. - Réplicas de lectura de Redis: promocionar shards de claves calientes para tener más réplicas y enrutar lecturas de forma aleatoria. Estrategia de Caché: Caché de tres niveles: borde de CDN → LRU en memoria → Redis Cluster → réplica de lectura de DB. Población de caché: escritura directa al crear, población perezosa en el primer fallo. Invalidación de caché: al eliminar o expirar un enlace, publicar un mensaje de invalidación en un canal Redis pub/sub; todas las instancias del Servicio de Redirección se suscriben y eliminan la clave de su LRU local. Las entradas de CDN expiran naturalmente a través de TTL. Particionamiento: - Almacén de Enlaces: particionar por hash de short_code (CockroachDB maneja esto automáticamente mediante sharding basado en rangos). No hay particiones calientes porque los códigos cortos se distribuyen uniformemente después de la codificación biyectiva. - Kafka: particionar eventos de clic por hash de short_code. Esto asegura que todos los eventos para un enlace dado vayan a la misma partición, permitiendo la agregación con estado por enlace sin mezclas. - ClickHouse: sharding por short_code, partición por fecha. Las consultas para la analítica de un solo enlace llegan a un shard; las consultas por rango de tiempo se benefician de la poda de particiones. Tráfico Multiregión: Desplegar en tres regiones: US-East, EU-West, AP-Southeast (cubre Norteamérica, Europa, Asia). - GeoDNS basado en DNS o Anycast dirige a los usuarios a la región más cercana. - Cada región es completamente independiente para lecturas (Servicio de Redirección + Redis + réplica de lectura de DB). - Las escrituras (creación de enlaces) van al Servicio de Creación de Enlaces de la región más cercana, que escribe en el nodo local de la DB distribuida globalmente. CockroachDB se replica a otras regiones en ~1–2 segundos. - Los eventos de analítica se procesan regionalmente y se reflejan a un clúster de analítica central para la agregación global. Esquema de Capacidad: - 8 mil millones de redirecciones/día = ~92,500 req/s promedio, ~300,000 req/s en pico (factor 3x). - Con una tasa de aciertos de CDN del 90%: ~30,000 req/s al origen en 3 regiones = ~10,000 req/s por región. - Cada instancia del Servicio de Redirección puede manejar ~5,000 req/s (principalmente aciertos de caché, CPU mínima). ~2–4 instancias por región con carga promedio, escalando automáticamente a 20+ en pico. - 120 millones de escrituras/día = ~1,400 escrituras/s promedio. El Servicio de Creación de Enlaces no es el cuello de botella. ───────────────────────────────────────── 6. ESTRATEGIA DE FIABILIDAD ───────────────────────────────────────── Objetivo de Disponibilidad: 99.99% = ~52 minutos de inactividad/año. Failover: - Cada región ejecuta múltiples instancias de cada servicio sin estado detrás de un balanceador de carga regional con comprobaciones de estado (fail open: elimina instancias no saludables en menos de 10 segundos). - Redis Cluster utiliza failover automático: si falla un shard primario, una réplica es promovida en ~15 segundos. Durante esta ventana, el Servicio de Redirección recurre a la réplica de lectura de la DB (latencia ligeramente mayor pero correcta). - Si falla una región completa, GeoDNS detecta el fallo mediante sondas de salud y redirige el tráfico a la región adyacente más cercana en ~30–60 segundos. Las regiones restantes deben absorber la carga; el escalado automático se encarga de esto. - CockroachDB / Aurora Global DB: failover automático a un nodo de otra región si la región primaria no está disponible. Para Aurora, esto implica una promoción manual o automatizada de una réplica de lectura a primaria (RTO ~1 minuto con automatización). Replicación de Datos: - Almacén de Enlaces: replicación síncrona dentro de una región (al menos 2 nodos), replicación asíncrona entre regiones (consenso de CockroachDB entre regiones, o Aurora Global DB ~1 s de latencia). Aceptamos consistencia eventual para lecturas entre regiones porque se cumple el SLA de propagación de 2 segundos. - Redis: cada shard tiene al menos una réplica en la misma región. No hay replicación de Redis entre regiones (Redis es una caché; la DB es la fuente de verdad). - Kafka: factor de replicación 3 dentro de cada región. Reflejo entre regiones solo para analítica (no para la corrección de la redirección). - ClickHouse: replicado dentro de la región de analítica usando ClickHouse Keeper (reemplazo de ZooKeeper). No se necesita replicación multiregión de ClickHouse ya que la analítica es eventualmente consistente. Copia de Seguridad: - Copias de seguridad lógicas diarias del Almacén de Enlaces a almacenamiento de objetos (S3), retenidas durante 30 días. - Exportaciones completas semanales de ClickHouse a almacenamiento de objetos, retenidas durante 90 días. - Datos de temas de Kafka retenidos durante 7 días (actúa como un búfer de reproducción para la recuperación de analítica). - La restauración de copias de seguridad se prueba mensualmente mediante simulacros de restauración automatizados en un entorno de staging. Comportamiento de Degradación: - Si Redis no está disponible: el Servicio de Redirección recurre a las réplicas de lectura de la DB. La latencia aumenta pero la corrección se mantiene. Alerta y escala automáticamente las réplicas de lectura de la DB. - Si la Cola de Analítica no está disponible: los eventos de clic se descartan (la analítica es eventualmente consistente; aceptamos esta pérdida). Las redirecciones nunca se bloquean por fallos de analítica. Un disyuntor en el Servicio de Redirección deshabilita la emisión de eventos si la cola no está en buen estado. - Si el Almacén de Enlaces primario no está disponible: la creación de nuevos enlaces falla (devuelve 503). Las redirecciones continúan usando datos cacheados y réplicas de lectura. Esto es aceptable porque la creación es menos crítica que la disponibilidad de redirección. - Si una región está completamente caída: failover de GeoDNS a la región adyacente. Los usuarios experimentan mayor latencia pero el servicio permanece disponible. - La limitación de tasa y la detección de abusos en la Pasarela API evitan que los DDoS abrumen el sistema. ───────────────────────────────────────── 7. COMPENSACIONES CLAVE Y ALTERNATIVAS RECHAZADAS ───────────────────────────────────────── Compensación 1: Redirecciones 302 vs. 301 Elegimos 302 (redirección temporal) por defecto. 301 (permanente) permitiría a los navegadores cachear la redirección indefinidamente, reduciendo la carga del origen. Sin embargo, 301 hace imposible rastrear clics repetidos del mismo navegador, rompe la analítica y nos impide actualizar o expirar enlaces (el navegador serviría la redirección cacheada para siempre). El costo del 302 es un mayor tráfico de origen, que mitigamos con CDN y caché en memoria. Para enlaces marcados explícitamente como permanentes por el propietario (y sin expiración), podríamos ofrecer 301 como opción, pero el valor predeterminado es 302. Compensación 2: Códigos Cortos Aleatorios vs. Codificación Basada en Contador Rechazado: Generar cadenas Base62 aleatorias de 7 caracteres y verificar colisiones en la DB. Motivo del rechazo: Con 120 millones de enlaces/día y un espacio de códigos de 3.5 billones, la probabilidad de colisión comienza baja pero aumenta con el tiempo. Más importante aún, cada creación requiere una lectura de DB para verificar colisiones, luego una escritura — dos viajes de ida y vuelta bajo contención. Con un enfoque basado en contador, el ID es único por construcción; no se necesita verificación de colisiones. El servicio de contador es una sobrecarga de coordinación menor pero es mucho más barata que las verificaciones de colisiones de DB a escala. La codificación biyectiva preserva el beneficio de imprevisibilidad de los códigos aleatorios. Compensación 3: Analítica Síncrona vs. Cola Asíncrona Rechazado: Escribir eventos de clic síncronamente en la DB de analítica durante la solicitud de redirección. Motivo del rechazo: Esto agregaría 10–50 ms de latencia a cada redirección (una escritura en ClickHouse o DB de analítica en el camino crítico), violando el SLA P95 < 80 ms. También crea una dependencia rígida entre la disponibilidad de redirección y la disponibilidad de analítica. El enfoque de cola asíncrona desacopla estas preocupaciones por completo. El costo es que la analítica es eventualmente consistente (retraso de 30–60 segundos), lo cual es explícitamente aceptable según los requisitos. Compensación 4: DB Global Única vs. DB Activa-Activa Multiregión Elegimos una DB distribuida globalmente (CockroachDB o Aurora Global) en lugar de un primario de una sola región con réplicas de lectura en todas partes. Un primario de una sola región nos daría semánticas de consistencia más simples pero haría que todas las escrituras fueran a una región (alta latencia para usuarios en otras regiones que crean enlaces, y un único punto de fallo para escrituras). La DB distribuida globalmente cuesta más y añade complejidad operativa, pero se justifica porque la latencia de creación de enlaces y la disponibilidad de escritura son importantes para la experiencia del usuario y el objetivo de disponibilidad del 99.99%. Compensación 5: ClickHouse vs. una DB de Series Temporales (p. ej., InfluxDB) para Analítica Rechazado: InfluxDB o TimescaleDB para almacenamiento de analítica. Motivo del rechazo: Las bases de datos de series temporales están optimizadas para métricas con un conjunto fijo de etiquetas. Nuestras consultas de analítica requieren GROUP BY país flexible, ventanas de tiempo arbitrarias y potencialmente uniones con metadatos de enlaces. El almacenamiento columnar de ClickHouse, la interfaz SQL y las vistas materializadas manejan estos patrones de forma más natural y a mayor escala. ClickHouse también admite agregaciones aproximadas (cuantiles, los más frecuentes) de forma nativa, lo cual es útil para la consulta de los 5 principales países a escala. ───────────────────────────────────────── RESUMEN DE JUSTIFICACIÓN DEL PRESUPUESTO ───────────────────────────────────────── Gastar más en: - Clústeres Redis multiregión: la latencia de redirección es el SLA central; los fallos de caché son costosos. - Almacén de Enlaces distribuido globalmente (CockroachDB / Aurora Global): la corrección de las redirecciones y la propagación global de 2 segundos lo requieren. - Capacidad de borde de CDN: la inversión de mayor apalancamiento para la latencia y disponibilidad de redirección. - Escalado automático para el Servicio de Redirección: el tráfico es muy variable y picos. Gastar menos en: - Infraestructura de analítica: la consistencia eventual es aceptable; un solo clúster central de ClickHouse con replicación es suficiente. No se necesita replicación de analítica multiregión. - Servicio de Creación de Enlaces: el volumen de escritura es de ~1,400/s, manejado trivialmente por unas pocas instancias. - Almacenamiento en frío / copias de seguridad: el almacenamiento de objetos es barato; sobreaprovisionar la retención en lugar de subaprovisionar. - Replicación Redis entre regiones: Redis es una caché respaldada por la DB; la replicación entre regiones añade costo y complejidad con un beneficio mínimo ya que la DB ya se replica.