Diseñar un servicio global de acortamiento de URL

1. Arquitectura de alto nivel con componentes principales y flujo de datos: * **Usuario/Cliente:** Interactúa con el servicio. * **API Gateway/Balanceador de Carga:** Punto de entrada para todas las solicitudes, maneja el enrutamiento, la limitación de velocidad y la terminación SSL. * **Servicio de Acortamiento:** Microservicio responsable de crear, actualizar y administrar URL cortas. Interactúa con la Base de Datos de Metadatos de Enlaces y la Caché. * **Servicio de Redirección:** Microservicio optimizado para redirecciones de alto rendimiento y baja latencia. Lee principalmente de la Caché, recurriendo a la Base de Datos de Metadatos de Enlaces. Publica eventos de clics en una Cola de Mensajes. * **Caché Distribuida (ej. Clúster Redis):** Almacena mapeos de `short_code` a `long_url` activos para redirecciones rápidas. * **Base de Datos de Metadatos de Enlaces (ej. Cassandra/DynamoDB):** Almacena todos los metadatos de las URL cortas (`short_code`, `long_url`, expiración, estado, etc.). * **Cola de Mensajes (ej. Kafka/Kinesis):** Ingiere eventos de clics brutos del Servicio de Redirección para procesamiento asíncrono. * **Procesador de Analíticas:** Consume eventos de clics brutos de la Cola de Mensajes, realiza agregaciones y los almacena en la Base de Datos de Analíticas. * **Base de Datos de Analíticas (ej. ClickHouse/Redshift):** Almacena datos de clics agregados para consultas. * **Lago de Datos (ej. S3):** Almacena eventos de clics brutos para retención a largo plazo y análisis más profundos. * **Servicio de Detección de Abusos:** Se integra con el Servicio de Acortamiento para escanear nuevas URL en busca de contenido malicioso. * **Monitoreo y Alertas:** Observabilidad para todos los componentes. **Flujo de Datos:** * **Solicitud de Acortamiento:** Usuario -> API Gateway -> Servicio de Acortamiento -> Detección de Abusos -> Base de Datos de Metadatos (escritura) -> Caché (escritura). * **Solicitud de Redirección:** Usuario -> CDN (opcional) -> Balanceador de Carga -> Servicio de Redirección -> Caché (lectura) -> Base de Datos de Metadatos (lectura de respaldo) -> Cola de Mensajes (evento de clic de escritura) -> Redirección a URL Larga. * **Procesamiento de Analíticas:** Cola de Mensajes -> Procesador de Analíticas -> Base de Datos de Analíticas (agregado de escritura) / Lago de Datos (bruto de escritura). 2. Opciones de almacenamiento para metadatos de enlaces, ruta de redirección y eventos de analíticas, con justificación: * **Metadatos de Enlaces (URL Corta -> URL Larga, Expiración, Estado, etc.):** * **Opción:** Base de datos NoSQL distribuida globalmente (ej. Apache Cassandra o Tablas Globales de AWS DynamoDB). * **Justificación:** Maneja un alto rendimiento de lectura/escritura (1.5 mil millones de lecturas/día, 120 millones de escrituras/mes), ofrece acceso de baja latencia desde múltiples regiones, proporciona alta disponibilidad y escala horizontalmente. La clave primaria sería el `short_code` para búsquedas eficientes. * **Ruta de Redirección (Mapeo de Código Corto -> URL Larga para búsqueda rápida):** * **Opción:** Caché distribuida en memoria (ej. Clúster Redis). * **Justificación:** Crucial para lograr una latencia p95 inferior a 80 ms para las redirecciones. Reduce significativamente la carga en la base de datos principal. Los enlaces activos se almacenan en caché agresivamente con TTL apropiados (ej. basados en la expiración del enlace o política LRU). Replicado entre regiones para acceso local. * **Eventos de Analíticas (Clics Brutos):** * **Opción:** Cola de Mensajes (ej. Apache Kafka o AWS Kinesis) para ingesta, seguida de un Lago de Datos (ej. AWS S3) para almacenamiento. * **Justificación:** Kafka/Kinesis maneja el inmenso volumen de escritura (1.5 mil millones de eventos/día) desacoplando la ruta de redirección del procesamiento de analíticas, asegurando que las redirecciones sigan siendo rápidas. S3 proporciona almacenamiento rentable y altamente duradero para eventos brutos retenidos durante 90 días, adecuado para procesamiento por lotes y análisis históricos. * **Analíticas Agregadas:** * **Opción:** Base de datos analítica columnar (ej. ClickHouse o AWS Redshift). * **Justificación:** Optimizada para consultas analíticas complejas y agregaciones sobre grandes conjuntos de datos. Permite consultas rápidas de datos agregados (ej. clics diarios, distribución de navegadores) en un plazo de 15 minutos, retenidos durante 2 años, sin afectar la base de datos operativa. 3. Estrategia de generación de códigos cortos, incluyendo cómo evitar colisiones y manejar alias personalizados: * **Estrategia de Generación de Códigos Cortos:** 1. **Generación de ID Distribuida:** Utilizar un generador de ID distribuido y único (ej. un servicio personalizado que genera IDs tipo Snowflake o UUID v7) para producir un ID entero de 64 bits globalmente único y monótonamente creciente. 2. **Codificación Base62:** Codificar este ID entero único en una cadena compacta Base62 (0-9, a-z, A-Z). Un ID de 64 bits puede producir un código corto de 6-10 caracteres, ofreciendo un vasto espacio de nombres (ej. 6 caracteres proporcionan 62^6 ≈ 56 mil millones de códigos únicos, suficientes para 120 millones/mes durante muchos años). * **Evitar Colisiones:** * **Basado en ID:** Dado que el ID subyacente está garantizado como único, el código corto codificado en Base62 también será único, evitando inherentemente colisiones para códigos generados por el sistema. * **Respaldo Aleatorio (para robustez):** Como opción secundaria o para casos de uso específicos, se podría usar un generador de cadenas aleatorias. En este caso, generar un código corto candidato, luego realizar una búsqueda rápida en la Base de Datos de Metadatos de Enlaces y la Caché. Si se detecta una colisión, regenerar e intentar varias veces. Esto es menos eficiente pero proporciona un respaldo. * **Alias Personalizados:** 1. **Envío por el Usuario:** Los usuarios envían su `custom_alias` deseado junto con la `long_url`. 2. **Validación:** El Servicio de Acortamiento valida el `custom_alias` (ej. longitud, caracteres permitidos, no ser una palabra reservada, no estar en lista negra). 3. **Verificación de Unicidad:** Antes de la creación, el Servicio de Acortamiento realiza una búsqueda en la Base de Datos de Metadatos para verificar si el `custom_alias` ya existe. Esta verificación debe ser fuertemente consistente. 4. **Reserva:** Si el `custom_alias` está disponible, se almacena directamente como el `short_code` en la Base de Datos de Metadatos. Si no está disponible, se rechaza la solicitud, solicitando al usuario que elija otro. 4. Plan de escalado para tráfico global, incluyendo caché, partición/fragmentación y consideraciones multirregión: * **Caché:** * **CDN:** Utilizar una Red de Entrega de Contenido (CDN) para activos estáticos y potencialmente para la resolución DNS de los enlaces cortos, dirigiendo a los usuarios a la ubicación de borde más cercana. * **Caché Distribuida (Clúster Redis):** Desplegar clústeres Redis en cada región geográfica principal. Estos clústeres almacenarán los mapeos `short_code` a `long_url` más accedidos. Las entradas de caché tienen TTL alineados con la expiración del enlace o una política LRU. Esto descarga significativamente la base de datos para las 1.5 mil millones de redirecciones diarias. * **Partición/Fragmentación:** * **Base de Datos de Metadatos de Enlaces:** Fragmentar la base de datos por el `short_code` (ej. usando un hash del código corto). Esto distribuye los datos y la carga de consultas entre múltiples nodos de base de datos. Cada fragmento se replica para alta disponibilidad dentro de una región. * **Base de Datos de Analíticas:** Particionar los eventos de clics brutos por tiempo (ej. particiones diarias o por hora) y los datos agregados por `short_code` y `fecha` para optimizar el rendimiento de las consultas y las políticas de retención de datos. * **Consideraciones Multirregión:** * **Activo-Activo para Redirecciones:** Desplegar el Servicio de Redirección, la Caché Distribuida y la Base de Datos de Metadatos de Enlaces (con replicación global) en múltiples regiones geográficas (ej. América del Norte, Europa, Asia-Pacífico). Geo-DNS dirige a los usuarios a la región más cercana, asegurando redirecciones de baja latencia a nivel mundial. * **Activo-Pasivo/Activo-Activo para Servicio de Acortamiento:** El Servicio de Acortamiento puede desplegarse activo-pasivo (primario en una región, réplicas en otras) o activo-activo, dependiendo de los requisitos de consistencia de escritura y la complejidad. Las escrituras son menos frecuentes que las lecturas, por lo que una latencia ligeramente mayor para la creación es aceptable si simplifica la consistencia. * **Replicación Global de Bases de Datos:** La Base de Datos de Metadatos de Enlaces (ej. Tablas Globales de DynamoDB o replicación multizona de Cassandra) asegura que los datos se repliquen entre regiones, permitiendo lecturas locales para redirecciones y proporcionando capacidades de recuperación ante desastres. * **Ingesta de Analíticas:** Las Colas de Mensajes regionales (Kafka/Kinesis) agregan eventos de clics localmente, que luego se transmiten a un Lago de Datos/Base de Datos de Analíticas central o se replican entre regiones para análisis consolidados. 5. Plan de confiabilidad que cubre fallos, claves activas, recuperación ante desastres y comportamiento en modo degradado: * **Fallos:** * **Redundancia:** Todos los servicios (Acortamiento, Redirección, Procesadores de Analíticas) se despliegan con redundancia N+1 en múltiples zonas de disponibilidad dentro de cada región, detrás de balanceadores de carga. * **Replicación de Base de Datos:** La Base de Datos de Metadatos y la Base de Datos de Analíticas utilizan replicación síncrona/asíncrona entre zonas de disponibilidad y regiones para garantizar la durabilidad y disponibilidad de los datos. * **Disyuntores y Reintentos:** Implementar disyuntores y mecanismos de reintento con retroceso exponencial en microservicios para prevenir fallos en cascada y manejar problemas transitorios de manera elegante. * **Monitoreo y Alertas:** Monitoreo integral de la salud del sistema, métricas de rendimiento y tasas de error con alertas automatizadas para problemas críticos. * **Claves Activas (Hot Keys):** * **Fragmentación de Caché:** La Caché Distribuida (Clúster Redis) está fragmentada, distribuyendo claves activas entre múltiples nodos para evitar que un solo nodo se convierta en un cuello de botella. * **Calentamiento de Caché:** Para enlaces activos anticipados (ej. de campañas importantes), precargarlos en la caché. * **Limitación de Velocidad:** Implementar limitación de velocidad en el API Gateway y los niveles del Servicio de Redirección para proteger los sistemas backend de picos de tráfico repentinos o ataques dirigidos a enlaces específicos. * **Recuperación ante Desastres:** * **Activo-Activo Multirregión:** El despliegue activo-activo para el Servicio de Redirección y la Base de Datos de Metadatos de Enlaces replicada globalmente proporciona recuperación ante desastres inherente para las redirecciones. Si una región falla, el tráfico se redirige automáticamente a otra región saludable a través de Geo-DNS. * **Copias de Seguridad de Datos:** Copias de seguridad regulares y automatizadas de todas las bases de datos críticas (Metadatos de Enlaces, Analíticas Agregadas) en almacenamiento duradero geográficamente separado (ej. S3). * **Playbooks de Recuperación:** Procedimientos documentados y probados regularmente para conmutación por error, restauración de datos y recuperación completa del sistema. * **Comportamiento en Modo Degradado:** * **Degradación de Analíticas:** Si la Cola de Mensajes o el Procesador de Analíticas experimentan problemas, los eventos de clics brutos pueden ser almacenados temporalmente o, en casos extremos, descartados (con alertas). Las redirecciones deben continuar funcionando sin interrupciones. * **Fallos/Ausencias en Caché:** Si la Caché Distribuida falla o experimenta alta latencia, el Servicio de Redirección recurre a consultar la Base de Datos de Metadatos de Enlaces. Esto resultará en una mayor latencia de redirección pero asegura la continuidad del servicio. Los disyuntores evitan sobrecargar la base de datos. * **Degradación del Servicio de Acortamiento:** Si el Servicio de Acortamiento está afectado, las redirecciones no se ven afectadas. Los usuarios podrían experimentar una creación de enlaces más lenta o una indisponibilidad temporal de la API de creación, pero los enlaces existentes continuarán funcionando. 6. APIs clave y modelos de datos principales: * **APIs Clave:** * **`POST /api/v1/shorten`** * **Descripción:** Crea una nueva URL corta. * **Cuerpo de la Solicitud:** `{"long_url": "string", "custom_alias": "string (opcional)", "expiration_date": "timestamp ISO 8601 (opcional)", "user_id": "string (opcional)"}` * **Respuesta:** `{"short_url": "string", "long_url": "string", "expires_at": "timestamp ISO 8601 (opcional)"}` * **`GET /{short_code}`** * **Descripción:** Redirige a la URL larga original. * **Respuesta:** Redirección HTTP 301/302 a `long_url`. * **`GET /api/v1/links/{short_code}/analytics`** * **Descripción:** Recupera las analíticas de clics para una URL corta específica. * **Respuesta:** `{"short_code": "string", "total_clicks": "integer", "daily_clicks": [{"date": "YYYY-MM-DD", "count": "integer"}], "browser_distribution": {"Chrome": 100, "Firefox": 50}, "country_distribution": {"US": 70, "DE": 30}}` * **`PUT /api/v1/links/{short_code}/status`** * **Descripción:** Actualiza el estado de una URL corta (ej. deshabilitar). * **Cuerpo de la Solicitud:** `{"status": "enum (active, disabled)"}` * **Respuesta:** `{"short_code": "string", "status": "string"}` * **Modelos de Datos Principales:** * **Metadatos de Enlaces (Almacenados en la Base de Datos de Metadatos de Enlaces): ``` { "short_code": "string (Clave Primaria)", "long_url": "string", "user_id": "string (Clave Foránea, opcional)", "created_at": "timestamp", "expires_at": "timestamp (opcional)", "status": "enum (active, disabled, expired)", "is_custom_alias": "boolean", "last_accessed_at": "timestamp (para LRU/limpieza)" } ``` * **Evento de Clic (Bruto - Almacenado en el Lago de Datos, ingerido a través de la Cola de Mensajes): ``` { "event_id": "UUID (Clave Primaria)", "short_code": "string", "timestamp": "timestamp", "ip_address_hash": "string (anonimizado/hasheado)", "user_agent": "string", "referrer": "string (opcional)", "country": "string (derivado de IP)", "city": "string (derivado de IP)" } ``` * **Analíticas Agregadas (Almacenadas en la Base de Datos de Analíticas): ``` { "short_code": "string (Clave de Partición)", "date": "date (Clave de Ordenación)", "total_clicks": "integer", "browser_counts": "map<string, integer>", "os_counts": "map<string, integer>", "country_counts": "map<string, integer>", "referrer_counts": "map<string, integer>" } ``` 7. Consideraciones sobre mitigación de abusos y seguridad: * **Detección de Enlaces Maliciosos:** * **Listas Negras:** Mantener una lista negra de dominios maliciosos, sitios de phishing y URL de spam continuamente actualizada. Las nuevas sumisiones de `long_url` se verifican contra esta lista. * **Escaneo en Tiempo Real:** Integrarse con APIs de navegación segura de terceros (ej. API de Navegación Segura de Google, VirusTotal) durante el proceso de creación de enlaces para escanear la `long_url` en busca de amenazas conocidas. * **Heurísticas:** Implementar algoritmos para detectar patrones de URL sospechosos, redirecciones excesivas o palabras clave comúnmente asociadas con abusos. * **Prevención de Spam y Abusos:** * **Limitación de Velocidad:** Aplicar límites de velocidad estrictos en la API `POST /shorten` por dirección IP y/o usuario autenticado para prevenir el spam automatizado. * **CAPTCHA/reCAPTCHA:** Para la creación de enlaces anónimos, implementar desafíos CAPTCHA para disuadir bots. * **Cuentas de Usuario:** Requerir autenticación de usuario para alias personalizados, límites de creación más altos y acceso a analíticas. Esto proporciona responsabilidad. * **Mecanismo de Denuncia:** Proporcionar una forma clara para que los usuarios denuncien enlaces cortos abusivos. Los enlaces denunciados se revisan y se deshabilitan si se encuentran maliciosos. * **Deshabilitación de Enlaces:** Permitir a los usuarios deshabilitar manualmente sus propios enlaces. El sistema también puede deshabilitar automáticamente los enlaces marcados por la detección de abusos o denunciados por otros. * **Consideraciones de Seguridad:** * **HTTPS en Todas Partes:** Forzar HTTPS para todos los puntos finales de la API y redirecciones para garantizar el cifrado de datos en tránsito. * **Validación y Sanitización de Entradas:** Validar y sanear rigurosamente todas las entradas proporcionadas por el usuario (`long_url`, `custom_alias`) para prevenir vulnerabilidades web comunes como XSS, inyección SQL y traversal de directorios. * **Control de Acceso:** Implementar control de acceso basado en roles (RBAC) para herramientas de gestión internas y funciones de gestión de enlaces específicas del usuario. * **Anonimización de Datos:** Anonimizar o hashear direcciones IP y otra información de identificación personal (PII) en los datos de analíticas de clics para cumplir con las regulaciones de privacidad (ej. GDPR, CCPA). * **Auditorías de Seguridad Regulares:** Realizar auditorías de seguridad periódicas, pruebas de penetración y escaneo de vulnerabilidades para identificar y remediar posibles debilidades. * **Protección DDoS:** Utilizar servicios de mitigación DDoS del proveedor de la nube (ej. AWS Shield, Cloudflare) en el borde. 8. Las principales compensaciones que realizó y por qué: * **Consistencia vs. Disponibilidad/Latencia para Redirecciones:** * **Compensación:** Priorizó la disponibilidad y baja latencia extremas para las redirecciones sobre la consistencia sólida para los metadatos de enlaces. Si bien la creación de enlaces requiere consistencia sólida para la unicidad de alias, un enlace recién creado o actualizado podría tardar unos milisegundos en propagarse a todas las cachés y réplicas de bases de datos a nivel mundial antes de estar consistentemente disponible para redirecciones. * **Por qué:** Las redirecciones son la operación más crítica y de mayor volumen. Un ligero retraso en que un nuevo enlace sea globalmente redirigible es aceptable, mientras que cualquier latencia significativa o tiempo de inactividad para las redirecciones afectaría gravemente la experiencia del usuario y los objetivos de confiabilidad del servicio. * **Costo vs. Rendimiento/Escalabilidad:** * **Compensación:** Optó por una arquitectura multirregión, replicada globalmente con caché extensiva y bases de datos especializadas, lo que inherentemente genera costos de infraestructura más altos en comparación con una configuración simple de una sola región. * **Por qué:** Las suposiciones de escala (1.5 mil millones de redirecciones/día, distribución global) y los objetivos de rendimiento (p95 < 80 ms) exigen este nivel de infraestructura distribuida. Se eligieron servicios en la nube de uso general y componentes de código abierto (como Kafka, Redis) siempre que fue posible para optimizar el costo y al mismo tiempo cumplir con los requisitos de rendimiento y escalabilidad. * **Granularidad de Datos vs. Costo de Almacenamiento/Rendimiento de Consultas para Analíticas:** * **Compensación:** Retiene eventos de clics brutos durante un período más corto (90 días) en un lago de datos rentable y almacena datos agregados durante un período más largo (2 años) en una base de datos de analíticas más performante, pero potencialmente más costosa. * **Por qué:** Almacenar 1.5 mil millones de eventos brutos diarios durante 2 años sería prohibitivamente costoso y lento para consultas en tiempo real. Este enfoque equilibra la necesidad de análisis históricos detallados (a través de datos brutos en S3) con el requisito de información agregada rápida (a través de la base de datos de analíticas) dentro de las restricciones presupuestarias. * **Longitud del Código Corto vs. Probabilidad de Colisión/Adivinabilidad:** * **Compensación:** Eligió la codificación Base62 para códigos cortos compactos (ej. 6-10 caracteres). Si bien un código puramente aleatorio de 6 caracteres tiene un riesgo teórico de colisión, la estrategia de generación basada en ID elimina esto para los códigos generados por el sistema. Para alias personalizados, la detección de colisiones es explícita. * **Por qué:** La compacidad es una característica central de un acortador de URL. La estrategia elegida proporciona un espacio de nombres lo suficientemente vasto como para evitar colisiones prácticas para códigos generados por el sistema y maneja las colisiones de alias personalizados de manera elegante, sin requerir códigos cortos excesivamente largos o complejos que anularían el propósito de acortar. * **Complejidad vs. Conjunto de Características:** * **Compensación:** Se centró en un sistema central robusto para acortar, redirigir y analíticas básicas, aceptando que características más avanzadas (ej. pruebas A/B, gestión de usuarios compleja, informes complejos) serían adiciones iterativas. * **Por qué:** Para cumplir con los objetivos agresivos de rendimiento y disponibilidad para la funcionalidad principal dentro de un alcance de diseño razonable. Agregar demasiadas características inicialmente aumentaría la complejidad, los posibles puntos de fallo y el tiempo de desarrollo, comprometiendo potencialmente la estabilidad del servicio principal.

DISEÑO: SERVICIO GLOBAL DE ACORTAMIENTO DE URLS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1. ARQUITECTURA DE ALTO NIVEL Y FLUJO DE DATOS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ COMPONENTES [Cliente] │ ▼ [DNS Anycast Global / GeoDNS] │ ▼ [PoPs de Borde Regional — CDN / proxy inverso Nginx] │ (acierto de caché → respuesta inmediata 301/302) │ (fallo de caché → reenviar al origen) ▼ [API Gateway Regional (limitación de tasa, autenticación, terminación TLS)] │ ├──► [Servicio de Redirección] ──► [Cluster Redis (caché de claves "calientes")] │ │ fallo │ ▼ │ [Almacén de Metadatos de Enlaces (Cassandra)] │ └──► [Servicio de Creación] ──► [Generador de ID (estilo Snowflake)] │ │ ├──► [Almacén de Metadatos de Enlaces (Cassandra)] └──► [Verificador de Alias Personalizados (Redis SET + Cassandra)] [Servicio de Redirección] ──► [Publicador de Eventos de Clic (Kafka)] │ ▼ [Procesador de Flujo (Flink / Spark Streaming)] │ ┌───────────┴────────────┐ ▼ ▼ [Almacén de Eventos Crudos [Almacén de Analíticas (S3 + Parquet, 90d)] Agregadas (ClickHouse, 2y)] FLUJO DE DATOS — REDIRECCIÓN (RUTA CRÍTICA) 1. El usuario visita https://sho.rt/aB3xYz 2. GeoDNS dirige al PoP regional más cercano. 3. La CDN de borde verifica su caché local en busca de la clave "aB3xYz". - ACIERTO: devuelve HTTP 301 (enorable en caché) o 302 (no enorable en caché para analíticas) inmediatamente. Dispara un beacon asíncrono a la canalización de analíticas. - FALLO: reenvía al Servicio de Redirección regional. 4. El Servicio de Redirección verifica el clúster Redis regional. - ACIERTO: devuelve la URL de destino, dispara un evento Kafka, responde 302. - FALLO: lee de Cassandra (réplica más cercana), rellena Redis, responde 302. 5. El consumidor de Kafka (Flink) procesa el evento de clic en segundos; las agregaciones llegan a ClickHouse en ~5 minutos; en el peor de los casos, 15 minutos. FLUJO DE DATOS — CREACIÓN 1. El cliente envía una solicitud POST al Servicio de Creación a través de la API Gateway. 2. Se aplican las comprobaciones de limitación de tasa y autenticación. 3. Si es un alias personalizado: comprueba Redis SET y Cassandra en busca de colisiones; rechaza si ya está en uso. 4. Si es autogenerado: ID Snowflake → codificación Base62 → código de 7 caracteres. 5. Escribe en Cassandra (escritura de quorum, RF=3). 6. Opcionalmente, calienta la caché de Redis inmediatamente. 7. Devuelve la URL corta al cliente. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2. ELECCIONES DE ALMACENAMIENTO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ALMACÉN DE METADATOS DE ENLACES — Apache Cassandra Justificación: - 120M de enlaces nuevos/mes ≈ 46 enlaces/segundo en promedio, con picos de 10 a 20 veces. Cassandra maneja un alto rendimiento de escritura con consistencia ajustable. - El patrón de acceso principal es la búsqueda de clave única por short_code — el modelo de clave de partición de Cassandra es ideal. - Replicación multizona (RF=3 por región, 3 regiones) proporciona una disponibilidad del 99,99 %+ sin un único punto de fallo. - Escala horizontalmente; no se necesitan transacciones costosas entre fragmentos. - El soporte TTL es nativo — los enlaces caducados se marcan automáticamente. - Costo: nodos genéricos, sin tarifas de licencia. Esquema (simplificado): Tabla: links short_code TEXT CLAVE PRIMARIA long_url TEXT owner_id UUID created_at TIMESTAMP expires_at TIMESTAMP (nulo; TTL de Cassandra establecido en la fila) is_disabled BOOLEAN is_custom BOOLEAN Alternativa considerada: DynamoDB — bueno pero dependencia del proveedor y costo a esta escala; PostgreSQL — no escalable horizontalmente para este volumen de escritura sin una complejidad de fragmentación significativa. CACHÉ DE RUTA DE REDIRECCIÓN — Cluster Redis (por región) - Almacena short_code → {long_url, is_disabled, expires_at} como un hash. - TTL en la entrada de caché = min(caducidad del enlace, 24 horas) para evitar entradas obsoletas. - Modo clúster con 6 nodos (3 primarios + 3 réplicas) por región; ~50 GB de RAM por región cubren el conjunto de trabajo "caliente" (los ~10M enlaces principales). - Política de desalojo: allkeys-lru. - Costo justificado: se espera una tasa de aciertos de Redis >95 %; cada fallo de caché cuesta una lectura de Cassandra (~5–10 ms) más latencia; a 17 000 redirecciones/segundo por región, evitar las lecturas de Cassandra es fundamental para el objetivo p95. ANALÍTICAS — EVENTOS CRUDOS: Apache Kafka + S3 (Parquet) - Kafka (clúster de 3 brokers por región, tema: click_events, 64 particiones) almacena en búfer los eventos de clic de forma duradera. - Los consumidores de Flink leen de Kafka, enriquecen los eventos (geo-IP, análisis de user-agent) y escriben archivos Parquet en S3 cada 5 minutos. - La política de ciclo de vida de S3 elimina los archivos crudos después de 90 días. - Costo: S3 es barato (~$0.023/GB/mes); 1.5 mil millones de eventos/día × ~200 bytes ≈ 300 GB/día → ~27 TB/90 días → ~$620/mes de almacenamiento. ANALÍTICAS — AGREGADAS: ClickHouse - Flink también escribe filas preagregadas (por short_code, por hora, por país/dispositivo) en ClickHouse. - El almacenamiento columnar y la ejecución vectorizada de ClickHouse hacen que las consultas de agregación de series temporales sean rápidas. - Factor de replicación 2 por región; retención de 2 años. - Tamaño estimado: ~1 TB/año agregado → muy manejable. - Alternativa considerada: Apache Druid — también excelente pero operativamente más pesado; ClickHouse es más simple para este caso de uso. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3. ESTRATEGIA DE GENERACIÓN DE CÓDIGOS CORTOS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CÓDIGOS AUTOGENERADOS Estrategia: ID distribuido estilo Snowflake → codificación Base62 1. Cada instancia del Servicio de Creación mantiene un ID de trabajador único (asignado al inicio a través de ZooKeeper o una tabla simple de base de datos). 2. Genera un ID Snowflake de 64 bits: [marca de tiempo de 41 bits ms | ID de trabajador de 10 bits | secuencia de 12 bits]. 3. Codifica Base62 el ID (caracteres: 0-9, a-z, A-Z). 4. Un entero de 64 bits se codifica en un máximo de 11 caracteres Base62; en la práctica, para los IDs generados en los primeros ~10 años, 7-8 caracteres son suficientes. 5. 7 caracteres en Base62 = 62^7 ≈ 3.5 billones de combinaciones — excede con creces los 120M/mes × 12 meses × 10 años = ~14.4 mil millones de enlaces. Prevención de colisiones: - Los IDs Snowflake son globalmente únicos por construcción (ID de trabajador + marca de tiempo + secuencia). No es posible ninguna colisión a menos que dos trabajadores compartan el mismo ID de trabajador, lo que se evita mediante el servicio de coordinación. - No es necesario un bucle "comprobar e insertar" para los códigos autogenerados. Adivinabilidad: - Los IDs Snowflake secuenciales codificados en Base62 no son aleatorios pero tampoco son fácilmente enumerables (el componente de marca de tiempo cambia cada milisegundo, la secuencia se reinicia). Para una mayor oscuridad, haz XOR de los 32 bits inferiores con un secreto por despliegue antes de codificar. Esto no es seguridad criptográfica, pero eleva la barrera para los ataques de enumeración. - Si se necesita una imprevisibilidad más fuerte: genera 6 bytes aleatorios → Base62 → código de 8 caracteres; comprueba Cassandra en busca de colisiones (raro a esta escala); reintenta en caso de colisión. La tasa de colisión esperada con 1.4 mil millones de enlaces existentes de un espacio de 62^8 ≈ 218 billones es insignificante (<0.001%). ALIAS PERSONALIZADOS 1. El usuario proporciona el alias deseado (por ejemplo, "mi-promo-2025"). 2. Validar: 3-50 caracteres, alfanuméricos + guiones, sin palabras reservadas (api, admin, health, etc.). 3. Comprobar Redis SET "custom_aliases" para existencia (comprobación similar a filtro bloom O(1), o un Redis SET). 4. Intentar INSERTAR EN Cassandra SI NO EXISTE (transacción ligera / comparar y establecer). 5. Si ya está en uso, devolver HTTP 409 Conflict. 6. Los alias personalizados se almacenan con is_custom=true; nunca se sobrescriben por la ruta de autogeneración. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4. PLAN DE ESCALADO PARA TRÁFICO GLOBAL ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ MATEMÁTICAS DEL TRÁFICO - 1.5 mil millones de redirecciones/día = ~17 400 req/segundo en promedio; asumir 3× pico = ~52 000 req/segundo. - 120M de creaciones/mes = ~46/segundo en promedio; 10× pico = ~460/segundo. La creación no es el cuello de botella. CAPAS DE CACHÉ Capa 1 — CDN/Borde (Cloudflare, Fastly o Nginx autoalojado en PoPs): - Caché de respuestas 301 para enlaces no caducables y no críticos para analíticas. Cache-Control: max-age=3600. - Usar 302 para enlaces donde se requieren analíticas por clic (la mayoría de los enlaces); estos omiten la caché de la CDN pero aún se benefician de la proximidad geográfica. - Tasa de aciertos estimada de la CDN para enlaces populares: 40–60 % del tráfico servido en el borde sin alcanzar el origen. Capa 2 — Cluster Redis Regional: - Cubre el ~40–60 % restante de las solicitudes que llegan al origen. - Tasa de aciertos esperada de Redis: >95 % de las solicitudes que llegan al origen. - Lecturas netas de Cassandra: <5 % de 17 400 req/segundo ≈ ~870 req/segundo — bien dentro de la capacidad de Cassandra. PARTICIONAMIENTO / FRAGMENTACIÓN Cassandra: - Clave de partición = short_code. El hashing consistente de Cassandra distribuye las particiones uniformemente entre los nodos. - No se necesita fragmentación manual; añadir nodos para reequilibrar automáticamente. - Evitar puntos calientes: short_code tiene alta cardinalidad; ninguna partición individual será desproporcionadamente grande. Redis: - Redis Cluster utiliza ranuras de hash (16 384 ranuras) distribuidas entre los nodos. Los hashes de short_code se mapean uniformemente. - Las claves "calientes" (enlaces virales) se manejan por separado — ver sección de Fiabilidad. Kafka: - 64 particiones por tema; clave de partición = short_code. Asegura el procesamiento ordenado por enlace mientras se paraleliza entre los consumidores. DESPLIEGUE MULTIRREGIÓN Regiones: US-East, EU-West, AP-Southeast (mínimo 3 para disponibilidad del 99,99 %). Cassandra: - Replicación multizona: RF=3 por centro de datos, 3 centros de datos. - Escrituras: LOCAL_QUORUM (2 de 3 nodos en DC local) para creación — rápido y consistente dentro de la región. - Lecturas: LOCAL_QUORUM para redirección — lee del DC más cercano. - La replicación entre DCs es asíncrona; la consistencia eventual entre regiones es aceptable para redirecciones (un enlace recién creado puede tardar <1 segundo en propagarse globalmente — aceptable). Redis: - Clúster independiente por región; sin replicación entre regiones (costo y complejidad no justificados). - El fallo de caché recurre a la réplica local de Cassandra. DNS: - GeoDNS dirige a los usuarios al API Gateway regional más cercano. - IP Anycast para el dominio de redirección asegura el enrutamiento de menor latencia. Servicio de Creación: - Sin estado; desplegar en cada región. Los IDs de trabajador son globalmente únicos (coordinados a través de un ZooKeeper global ligero o una tabla de base de datos simple con prefijo de región). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5. PLAN DE FIABILIDAD ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ESCENARIOS DE FALLO Y MITIGACIONES Fallo de nodo Redis: - Redis Cluster promueve una réplica automáticamente (típicamente <30 segundos). - Durante la conmutación por error, las solicitudes pasan a Cassandra. Cassandra puede manejar el estallido (~870 req/segundo normalmente; estallido a ~17 000 req/segundo durante <30 segundos es manejable con el aprovisionamiento adecuado — dimensionar Cassandra para 2× la carga pico esperada de lectura). - Disyuntor en el Servicio de Redirección: si Redis no está disponible, omite la caché y lee directamente de Cassandra. Fallo de nodo Cassandra: - RF=3 con LOCAL_QUORUM significa que el fallo de 1 nodo es transparente; el fallo de 2 nodos degrada a LOCAL_ONE (aún funcional, ligeramente menos consistente). - El protocolo de chismes de Cassandra detecta fallos en segundos; el hinted handoff asegura que las escrituras no se pierdan. Fallo de región completa: - Las comprobaciones de estado de GeoDNS detectan la indisponibilidad de la región en 30–60 segundos y redirigen el tráfico a la siguiente región más cercana. - La replicación entre DCs de Cassandra asegura que los datos estén disponibles en las regiones supervivientes. - Objetivo: RTO < 2 minutos, RPO = 0 para metadatos de enlaces (escrituras de quorum síncronas dentro del DC; replicación asíncrona entre DCs significa <1 segundo de posible pérdida de datos para creaciones muy recientes — aceptable). CLAVES "CALIENTES" (ENLACES VIRALES) Problema: un solo código corto viral podría generar millones de solicitudes/segundo, abrumando una ranura Redis o una partición Cassandra. Mitigaciones: 1. Caché local en memoria en cada instancia del Servicio de Redirección (por ejemplo, Caffeine, LRU de 10 000 entradas, TTL de 30 segundos). Absorbe solicitudes repetidas dentro de un solo pod sin alcanzar Redis. 2. Replicación de claves Redis: para claves "calientes" detectadas (monitorizadas a través de Redis MONITOR o un contador de ventana deslizante), replica la clave en múltiples ranuras Redis con un sufijo (por ejemplo, aB3xYz:0, aB3xYz:1 ... aB3xYz:N) y selecciona aleatoriamente una en la lectura. 3. Caché CDN: para enlaces no analíticos, envía enlaces "calientes" a la CDN con un TTL corto (60 segundos) para absorber el tráfico en el borde. 4. Cassandra: las claves "calientes" no son un problema porque Redis absorbe >99 % de las lecturas para enlaces "calientes". RECUPERACIÓN ANTE DESASTRES - Cassandra: instantáneas diarias a S3 (snapshot de nodetool). La replicación entre regiones proporciona DR en vivo. - Redis: persistencia de Redis (AOF + RDB) a disco local; Redis es una caché — la pérdida es aceptable (recurre a Cassandra). No se necesita replicación de Redis entre regiones. - Kafka: factor de replicación 3 dentro de la región; Kafka MirrorMaker 2 entre regiones replica eventos de clic a una región secundaria para DR de analíticas. - ClickHouse: tablas replicadas (ReplicatedMergeTree); copias de seguridad diarias a S3. COMPORTAMIENTO EN MODO DEGRADADO - Si la canalización de analíticas (Kafka/Flink) está caída: las redirecciones continúan sin verse afectadas. Los eventos de clic se almacenan en búfer en Kafka (retención de 7 días); las analíticas se ponen al día cuando la canalización se recupera. La SLA para analíticas (frescura de 15 minutos) puede violarse temporalmente — aceptable. - Si el Servicio de Creación está caído: las redirecciones existentes continúan funcionando (la ruta de lectura es independiente). La creación de nuevos enlaces falla con gracia con 503. - Si Cassandra está degradada (quorum no disponible): el Servicio de Redirección recurre al modo solo Redis. Los enlaces que no están en Redis devuelven 503 en lugar de una redirección incorrecta. Este es un modo degradado de último recurso. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 6. APIS CLAVE Y MODELOS DE DATOS CENTRALES ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ API REST POST /api/v1/links Solicitud: { "long_url": "https://example.com/very/long/path?q=1", "custom_alias": "my-promo", // opcional "expires_at": "2026-01-01T00:00:00Z", // ISO-8601 opcional "owner_id": "uuid" // del token de autenticación } Respuesta 201: { "short_code": "aB3xYz", "short_url": "https://sho.rt/aB3xYz", "long_url": "https://example.com/very/long/path?q=1", "expires_at": "2026-01-01T00:00:00Z", "created_at": "2025-01-15T10:00:00Z" } Errores: 400 (URL inválida), 409 (alias ocupado), 422 (URL bloqueada/maliciosa), 429 (limitado en tasa) GET /{short_code} Respuesta 302: Location: <long_url> Respuesta 301: Location: <long_url> (para enlaces enorables en caché, no analíticos) Respuesta 404: enlace no encontrado Respuesta 410: enlace caducado o deshabilitado PATCH /api/v1/links/{short_code} Solicitud: { "is_disabled": true } // o actualizar expires_at Respuesta 200: objeto de enlace actualizado Auth: solo propietario DELETE /api/v1/links/{short_code} Respuesta 204 Auth: solo propietario GET /api/v1/links/{short_code}/analytics Parámetros de consulta: from, to, granularity (hour/day), group_by (country/device/referrer) Respuesta 200: { "short_code": "aB3xYz", "total_clicks": 142300, "series": [ { "timestamp": "2025-01-15T10:00:00Z", "clicks": 1200, "country": "US" }, ... ] } MODELOS DE DATOS CENTRALES links (Cassandra) short_code TEXT CLAVE PRIMARIA long_url TEXT NO NULO owner_id UUID created_at TIMESTAMP expires_at TIMESTAMP (nulo; también establecido como TTL de fila de Cassandra) is_disabled BOOLEAN POR DEFECTO false is_custom BOOLEAN POR DEFECTO false abuse_flags INT POR DEFECTO 0 click_events (Kafka → S3 Parquet, crudo) event_id UUID short_code TEXT timestamp TIMESTAMP ip_hash TEXT (SHA-256 de IP, por privacidad) country_code TEXT (de la búsqueda geo-IP) user_agent TEXT referrer TEXT region TEXT (región de servicio) analytics_hourly (ClickHouse, agregado) short_code TEXT hour DateTime country_code TEXT device_type TEXT (móvil/escritorio/bot) referrer_domain TEXT click_count UInt64 unique_ips UInt64 (aproximación HyperLogLog) PRIMARY KEY (short_code, hour, country_code, device_type) ENGINE = ReplicatedMergeTree users (PostgreSQL — tabla pequeña, no en ruta crítica) user_id UUID PRIMARY KEY email TEXT ÚNICO api_key_hash TEXT rate_limit_tier TEXT created_at TIMESTAMP ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 7. MITIGACIÓN DE ABUSOS Y SEGURIDAD ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ DETECCIÓN DE URLS MALICIOSAS 1. Comprobación de la API Safe Browsing en el momento de la creación: enviar long_url a Google Safe Browsing (o equivalente) antes de almacenarla. Rechazar con 422 si se marca. Latencia: ~50–100 ms, aceptable dentro de la SLA de creación de 300 ms. 2. Lista negra de dominios: mantener un Redis SET de dominios conocidos como malos (phishing, malware). Comprobar síncronamente en la creación. Actualizado cada hora a partir de fuentes de inteligencia de amenazas. 3. Reescaneo asíncrono: un trabajo en segundo plano escanea periódicamente las URLS almacenadas contra listas negras actualizadas. Si una URL previamente limpia se marca más tarde, establece is_disabled=true y abuse_flags=1. El Servicio de Redirección comprueba is_disabled en cada solicitud (desde la caché). 4. Normalización de URL: analizar y normalizar URLS en la creación para evitar ofuscación (por ejemplo, trucos de codificación de URL, ataques de homógrafos en nombres de dominio — comprobar homógrafos IDN). LIMITACIÓN DE TASA - Límite de tasa por IP en la API Gateway: 10 creaciones/minuto para anónimos, 100/minuto para usuarios autenticados, configurable por nivel. - Contador de ventana deslizante basado en Redis (cubo de tokens) por IP/usuario. - Límite de tasa global: 10 000 creaciones/segundo en todo el sistema (muy por encima del pico esperado de 460/segundo). - Ruta de redirección: sin límite de tasa (público); protección DDoS a través de CDN (mitigación DDoS de Cloudflare o equivalente). PREVENCIÓN DE ENUMERACIÓN - Los códigos cortos no son puramente secuenciales (ofuscación Snowflake XOR o generación aleatoria). - Ningún punto final de API para listar todos los códigos cortos. - Intentos de redirección masiva no autenticados (>1000 códigos únicos/minuto desde una IP) activan un desafío CAPTCHA o un bloqueo temporal de IP. AUTENTICACIÓN Y AUTORIZACIÓN - Clave API o OAuth 2.0 JWT para puntos finales de creación y gestión. - PATCH/DELETE requieren verificación de propiedad (owner_id coincide con el token). - API de administrador (punto final interno separado) para que el equipo de abusos deshabilite enlaces. PRIVACIDAD - Las direcciones IP se hashean (SHA-256 + sal por despliegue) antes de almacenarlas en analíticas. Las IP crudas nunca se persisten. - GDPR: los usuarios pueden solicitar la eliminación de sus enlaces y analíticas asociadas. Eliminación de Cassandra + etiqueta de ciclo de vida de S3 para eventos crudos. APLICACIÓN DE HTTPS - Todas las URLS cortas se sirven solo a través de HTTPS. Las solicitudes HTTP se redirigen a HTTPS en el borde. - Encabezado HSTS en el dominio corto. PREVENCIÓN DE REDIRECCIÓN ABIERTA - Solo redirigir a URLS que fueron registradas explícitamente. Sin construcción dinámica de URLS a partir de la entrada del usuario en el momento de la redirección. - Validar el esquema de long_url en la creación: solo se permiten http:// y https://. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 8. COMPENSACIONES CLAVE Y JUSTIFICACIONES ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ COMPENSACIÓN 1: 302 vs 301 para redirecciones - 301 (permanente) es almacenado en caché por los navegadores indefinidamente → menor latencia, carga cero del servidor para visitas repetidas. Pero se pierden las analíticas (el navegador nunca vuelve a llamar al servidor), y deshabilitar o expirar un enlace es imposible para los clientes en caché. - 302 (temporal) golpea el servidor cada vez → analíticas completas, deshabilitación/expiración instantánea. Latencia ligeramente mayor para visitas repetidas. - Decisión: Usar 302 por defecto para todos los enlaces. Ofrecer 301 como opción para usuarios que explícitamente desean el máximo caché y no necesitan analíticas. Este es el valor predeterminado correcto para un servicio que vende analíticas. COMPENSACIÓN 2: Cassandra vs. base de datos relacional para metadatos de enlaces - Una base de datos relacional (PostgreSQL) sería más simple de operar y admite consultas más ricas. Pero escalar horizontalmente para 46 escrituras/segundo en promedio (con picos de 10–20×) y 17 000 lecturas/segundo es doloroso sin una complejidad de fragmentación significativa. - Cassandra sacrifica el soporte de consultas ricas (sin joins, índices secundarios limitados) por escalabilidad horizontal lineal y replicación multizona. Dado que la única consulta "caliente" es la búsqueda de clave única por short_code, esta compensación es totalmente aceptable. COMPENSACIÓN 3: Consistencia eventual para la propagación de enlaces entre regiones - Un enlace creado en US-East puede no ser visible inmediatamente en AP-Southeast (retraso de subsegundo). Un usuario que crea un enlace y lo comparte inmediatamente a nivel mundial podría ver un breve 404 en regiones distantes. - Alternativa: escrituras síncronas entre regiones (EACH_QUORUM) — garantiza la consistencia global pero añade 100–200 ms de latencia a la creación (viola la SLA de 300 ms bajo condiciones adversas) y reduce la disponibilidad. - Decisión: Aceptar la consistencia eventual. La ventana de propagación de subsegundo es una compensación de UX aceptable. Documentarla. La SLA de creación se cumple. COMPENSACIÓN 4: IDs Snowflake vs. códigos aleatorios - Los IDs Snowflake son monótonamente crecientes → ligeramente predecibles pero sin riesgo de colisión, sin necesidad de comprobación de base de datos, operativamente simples. - Códigos aleatorios → mejor imprevisibilidad, pero requieren una comprobación de colisión (rara pero añade latencia y complejidad). - Decisión: Snowflake + ofuscación XOR para códigos autogenerados. Ofrece un buen equilibrio de simplicidad, rendimiento y previsibilidad razonable. Códigos aleatorios disponibles como opción para casos de uso sensibles a la seguridad. COMPENSACIÓN 5: Canalización de analíticas separada vs. escrituras síncronas - Escribir analíticas síncronamente en una base de datos en cada redirección añadiría latencia a la ruta crítica y crearía un cuello de botella de escritura a 17 000 req/segundo. - La canalización asíncrona de Kafka desacopla completamente las analíticas de la ruta de redirección. El costo es la consistencia eventual en las analíticas (hasta 15 minutos) y la complejidad operativa añadida (Kafka + Flink + ClickHouse). - Decisión: Canalización asíncrona. El requisito de frescura de analíticas de 15 minutos lo permite explícitamente. La ruta de redirección debe ser rápida; las analíticas pueden retrasarse. COMPENSACIÓN 6: Alcance del caché de la CDN - Almacenar en caché todas las redirecciones en la CDN (301) proporcionaría el máximo rendimiento pero rompería las analíticas y la deshabilitación/expiración. - Almacenar en caché solo enlaces no analíticos y no caducables en la CDN es un punto intermedio. - Decisión: La CDN solo almacena en caché los enlaces marcados explícitamente como enorables en caché (opción 301). Todos los demás usan 302 con Cache-Control: no-store. Este es el valor predeterminado correcto para un servicio donde las analíticas son una característica central. COMPENSACIÓN 7: ClickHouse vs. Druid vs. BigQuery para analíticas - BigQuery: totalmente gestionado, sin operaciones, pero alta latencia de consulta (segundos) y costo a este volumen de eventos. - Druid: excelente para analíticas en tiempo real pero operativamente complejo (nodos ZooKeeper, Broker, Historical, MiddleManager). - ClickHouse: más simple de operar que Druid, excelente rendimiento de consulta, rentable en hardware genérico, buena integración con Kafka. - Decisión: ClickHouse. El mejor equilibrio de simplicidad operativa, rendimiento y costo para este caso de uso. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ RESUMEN DE CAPACIDAD (DESPLIEGUE DE 3 REGIONES) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Servicio de Redirección: ~30 pods × 3 regiones (escalado automático, sin estado) Servicio de Creación: ~5 pods × 3 regiones Cassandra: 9 nodos × 3 regiones (RF=3 por DC), ~2 TB SSD cada uno Cluster Redis: 6 nodos × 3 regiones, 50 GB RAM cada uno Kafka: 3 brokers × 3 regiones Flink: 10 gestores de tareas × 3 regiones ClickHouse: 4 nodos × 3 regiones (replicados) S3: ~27 TB de eventos crudos/90 días + ~3 TB agregados/2 años Costo mensual estimado de infraestructura: $15,000–$25,000 (VMs de nube genéricas), dominado por el almacenamiento de Cassandra y la memoria de Redis. La salida de la CDN es el costo variable más grande a escala.