Diseñar un servicio global de acortamiento de URL

1. Arquitectura de Alto Nivel y Flujos de Solicitudes: **Componentes Principales:** * **API Gateway/Balanceadores de Carga:** Punto de entrada para todas las solicitudes de usuario, maneja el enrutamiento, la autenticación y la limitación de velocidad. * **Servicio de Acortamiento (Shorten Service):** Microservicio responsable de crear, actualizar y eliminar enlaces cortos. Maneja la validación de alias personalizados y la lógica de expiración. * **Servicio de Redirección (Redirect Service):** Microservicio optimizado para redirección de alto rendimiento y baja latencia. Registra eventos de clics. * **Caché Distribuida (ej. Redis Cluster):** Almacenamiento principal para las correspondencias `short_code` a `long_url` para servir redirecciones con latencia mínima. * **Base de Datos SQL Distribuida (ej. CockroachDB, Google Spanner):** Almacena la fuente de verdad autorizada para todos los metadatos de los enlaces, garantizando la unicidad global y la consistencia fuerte. * **Cola de Mensajes (ej. Apache Kafka):** Ingiere eventos de clics de alto volumen del Servicio de Redirección, desacoplándolo del procesamiento de análisis. * **Procesador de Análisis (ej. Apache Flink/Spark Streaming):** Consume eventos de clics de la Cola de Mensajes, realiza agregaciones en tiempo real y almacena datos. * **Almacén de Datos (Data Warehouse) (ej. ClickHouse, Snowflake, BigQuery):** Almacena datos de análisis brutos y agregados para informes y análisis. * **CDN (ej. Cloudflare, Akamai):** Distribuye activos estáticos, proporciona resolución DNS global y puede ofrecer enrutamiento geográfico al centro de datos más cercano. **Flujos de Solicitudes:** * **Creación de Enlace Corto:** 1. El usuario/cliente envía una solicitud al API Gateway. 2. El API Gateway la enruta a un Balanceador de Carga, luego al Servicio de Acortamiento. 3. El Servicio de Acortamiento genera un `short_code` único (o valida un alias personalizado). 4. Almacena el `short_code`, `long_url`, `expires_at` y otros metadatos en la Base de Datos SQL Distribuida. 5. Envía la nueva correspondencia `short_code` -> `long_url` a la Caché Distribuida. 6. El Servicio de Acortamiento devuelve el `short_code` al usuario. * **Redirección de Enlace Corto:** 1. El usuario/cliente accede a una URL corta, que se enruta a través de CDN/GeoDNS al centro de datos más cercano del Balanceador de Carga. 2. El Balanceador de Carga dirige a la solicitud al Servicio de Redirección. 3. El Servicio de Redirección primero verifica en la Caché Distribuida la correspondencia `short_code` -> `long_url`. 4. *Acertada en Caché (Cache Hit):* Si se encuentra y está activa, emite inmediatamente una redirección HTTP 301/302 a la `long_url`. 5. *Fallo en Caché (Cache Miss):* Si no se encuentra, consulta la Base de Datos SQL Distribuida. Si se encuentra y está activa, rellena la caché y luego redirige. Si no se encuentra, ha expirado o ha sido eliminada, devuelve un error 404. 6. De forma asíncrona, el Servicio de Redirección publica un evento de clic (que contiene `short_code`, `timestamp`, `country`, `device_type`, `referrer_domain`) en la Cola de Mensajes. * **Procesamiento de Análisis:** 1. El Procesador de Análisis consume eventos de clics de la Cola de Mensajes. 2. Realiza procesamiento en tiempo real (ej. agregación, enriquecimiento). 3. Los datos brutos y agregados se almacenan en el Almacén de Datos para informes. 2. Modelo de Datos y Elecciones de Almacenamiento: * **Enlaces y Alias (Base de Datos SQL Distribuida - CockroachDB/Google Spanner):** * **Tabla `links`:** * `short_code` (VARCHAR, Clave Primaria): El identificador corto único. * `long_url` (VARCHAR): La URL original (hasta 500 bytes). * `user_id` (UUID, Indexado, FK): Opcional, para la propiedad del enlace. * `created_at` (TIMESTAMP): Cuándo se creó el enlace. * `expires_at` (TIMESTAMP, Nulo, Indexado): Cuándo debería expirar el enlace. * `status` (ENUM: 'active', 'expired', 'deleted', Indexado): Estado actual del enlace. * `is_custom_alias` (BOOLEAN): Verdadero si es un alias definido por el usuario. * `click_count` (BIGINT): Conteo desnormalizado y eventualmente consistente de clics (actualizado por análisis). * *Justificación:* Elegida por sus garantías de consistencia fuerte (crítica para la unicidad global de `short_code` y `custom_alias`), propiedades ACID y capacidades nativas de replicación multiregión. Esto simplifica la gestión global de datos y asegura la integridad de los mismos. * **Eventos de Análisis (Cola de Mensajes - Apache Kafka, Almacén de Datos - ClickHouse/Snowflake):** * **Tema de Kafka (`click_events`):** Almacena mensajes de eventos de clics brutos (ej. JSON/Protobuf). * **Tabla del Almacén de Datos (`raw_clicks`):** * `event_id` (UUID, Clave Primaria) * `short_code` (VARCHAR, Indexado) * `timestamp` (TIMESTAMP, Indexado) * `country` (VARCHAR, Indexado) * `device_type` (VARCHAR) * `referrer_domain` (VARCHAR) * **Tabla del Almacén de Datos (`aggregated_clicks`):** (ej. agregaciones horarias/diarias) * `short_code` (VARCHAR, PK) * `aggregation_time` (TIMESTAMP, PK) * `country` (VARCHAR, PK) * `total_clicks` (BIGINT) * *Justificación:* Kafka proporciona ingesta y desacoplamiento tolerantes a fallos y de alto rendimiento. ClickHouse/Snowflake están optimizados para consultas analíticas sobre conjuntos de datos masivos, soportando el requisito de consistencia eventual para el análisis. 3. Estrategia de Escalado para Tráfico Intensivo en Lectura: * **Caché Distribuida (Redis Cluster):** Esta es la capa principal de escalado para las redirecciones. Almacenará las correspondencias `short_code` a `long_url` en memoria, manejando la gran mayoría de los 4 mil millones de redirecciones diarias. Redis Cluster ofrece escalado horizontal y alta disponibilidad a través de fragmentación (sharding) y replicación. * **CDN Global y Enrutamiento Geográfico:** Una CDN (ej. Cloudflare) servirá activos estáticos y proporcionará enrutamiento inteligente basado en DNS (GeoDNS) para dirigir a los usuarios al centro de datos geográficamente más cercano, minimizando la latencia de redirección. * **Servicios sin Estado (Stateless):** Tanto los servicios de Acortamiento como de Redirección están diseñados para ser sin estado, lo que permite un escalado horizontal fácil mediante la adición de más instancias detrás de balanceadores de carga en cada región. Los grupos de autoescalado ajustarán dinámicamente la capacidad según el tráfico. * **Réplicas de Lectura de Base de Datos/Lecturas Distribuidas:** La Base de Datos SQL Distribuida manejará inherentemente las lecturas distribuidas a través de sus nodos. Si las tasas de aciertos de caché son más bajas de lo esperado, o para enlaces menos populares, la capacidad de la base de datos para escalar lecturas a través de su clúster será crucial. * **Generación de Códigos Cortos:** Para la creación de enlaces de alto volumen, los códigos cortos pueden pregenerarse en lotes y almacenarse, o se puede utilizar un servicio de generación de IDs distribuidos (ej. inspirado en Twitter Snowflake) para asegurar códigos únicos y no secuenciales, evitando puntos calientes (hotspots) en la base de datos. 4. Estrategia de Fiabilidad: * **Conmutación por Error (Failover):** * **Despliegue Multirregional:** Todos los servicios críticos (Acortamiento, Redirección, Base de Datos, Caché, Cola de Mensajes) se despliegan en una configuración activa-activa en al menos tres regiones geográficamente distintas (ej. América del Norte, Europa, Asia). * **Conmutación por Error a Nivel de Servicio:** Los servicios se despliegan en grupos de autoescalado en múltiples Zonas de Disponibilidad dentro de cada región. Los balanceadores de carga detectan y enrutan automáticamente el tráfico lejos de las instancias no saludables. * **Conmutación por Error de Base de Datos:** La Base de Datos SQL Distribuida proporciona replicación multiregional incorporada y mecanismos de conmutación por error automática (ej. consenso Raft en CockroachDB) para asegurar la operación continua incluso si fallan nodos o zonas enteras. * **Conmutación por Error de Caché:** Redis Cluster proporciona replicación para redundancia de datos y conmutación por error automática de nodos maestros. * **Conmutación por Error de Cola de Mensajes:** Los clústeres de Kafka se despliegan con replicación (ej. 3 brokers, factor de replicación 3) en múltiples Zonas de Disponibilidad para tolerar fallos de brokers. * **Decisiones de Consistencia:** * **Consistencia Fuerte (Creación de Enlaces/Alias):** La Base de Datos SQL Distribuida asegura consistencia fuerte para la unicidad de `short_code` y `custom_alias`. Esto es crítico para prevenir colisiones y mantener la integridad de los datos. * **Consistencia Eventual (Redirecciones):** La Caché Distribuida opera con consistencia eventual. Cuando un enlace se crea, actualiza (ej. cambia `expires_at`) o elimina, se publica un evento en un tema de invalidación de caché (ej. Kafka). Los nodos de caché se suscriben a este tema e invalidan/actualizan sus entradas. Un TTL corto (ej. 1-5 minutos) en las entradas de caché actúa como respaldo para prevenir la desactualización indefinida. * **Consistencia Eventual (Análisis):** Los datos de análisis son eventualmente consistentes dentro de los 5 minutos, manejados por la Cola de Mensajes asíncrona y el procesamiento de flujo. Esto prioriza el rendimiento de la redirección sobre las actualizaciones inmediatas de análisis. * **Manejo de Interrupciones Regionales:** * **Balanceo de Carga Global/DNS:** Servicios de DNS inteligentes (ej. GeoDNS) y balanceadores de carga globales detectan automáticamente fallos regionales y redirigen el tráfico a regiones activas y saludables. * **Replicación de Datos:** La Base de Datos SQL Distribuida replica todos los datos de enlaces a través de las regiones activas. Si una región deja de estar disponible, otras regiones pueden continuar sirviendo solicitudes con una pérdida mínima de datos e impacto en la latencia. * **Degradación Elegante (Graceful Degradation):** Si el Servicio de Análisis o la Cola de Mensajes experimentan problemas, el Servicio de Redirección está diseñado para continuar funcionando, almacenando temporalmente eventos localmente o, en casos extremos, descartándolos, priorizando la funcionalidad principal de redirección. 5. Compromisos Clave, Cuellos de Botella y Riesgos: * **Compromisos Clave:** * **Consistencia vs. Latencia:** La consistencia fuerte para la creación de enlaces (a través de SQL Distribuido) asegura la integridad de los datos, pero puede implicar una latencia de escritura ligeramente mayor. Para las redirecciones, se elige la consistencia eventual a través de una caché altamente optimizada para lograr una latencia inferior a 80 ms. * **Tamaño de Caché vs. Costo:** El almacenamiento en caché extensivo es vital para el rendimiento de las redirecciones, pero requiere recursos de memoria significativos, lo que genera mayores costos de infraestructura. Se debe lograr un equilibrio entre la tasa de aciertos de caché y el gasto operativo. * **Longitud del Código Corto vs. Tamaño del Espacio de Nombres:** Los códigos más cortos son más amigables para el usuario, pero aumentan la probabilidad de colisiones y limitan el número total de enlaces únicos. Un código base62 de 7-10 caracteres proporciona un espacio de nombres vasto y práctico. * **Cuellos de Botella:** * **Capacidad de la Caché Distribuida:** Si la caché no puede manejar el rendimiento máximo de lectura o si el conjunto de trabajo activo de enlaces excede su capacidad de memoria, las redirecciones recurrirán a la base de datos, aumentando la latencia y la carga de la base de datos. * **Rendimiento de Escritura de la Base de Datos:** Aunque la creación de enlaces tiene un volumen menor que las redirecciones, 120 millones de enlaces/día es considerable. La Base de Datos SQL Distribuida debe poder manejar esta carga de escritura entre regiones sin convertirse en un cuello de botella. * **Latencia de Red entre Regiones:** La replicación de datos entre regiones y las comprobaciones de consistencia, especialmente para operaciones de escritura en un sistema distribuido globalmente, pueden introducir latencia inherente. * **Riesgos y Mitigaciones:** * **Riesgo 1: Colisiones de Códigos Cortos (especialmente para generación aleatoria):** * *Mitigación:* Utilizar un `short_code` suficientemente largo (ej. 7-10 caracteres usando base62: a-z, A-Z, 0-9). Implementar una estrategia de generación robusta: pregenerar un gran grupo de códigos únicos, usar un generador de IDs distribuidos (ej. tipo Snowflake) para generar IDs únicos y luego convertirlos a base62, o para alias personalizados, realizar una verificación directa de unicidad en la base de datos con bloqueo optimista y reintentos. * **Riesgo 2: Desactualización de Caché para Enlaces Expirados/Eliminados:** * *Mitigación:* Implementar un mecanismo de invalidación de caché en tiempo real. Cuando el estado de un enlace cambia (ej. se alcanza `expires_at`, se establece `status` a 'deleted'), el Servicio de Acortamiento (o un trabajo de fondo dedicado) publica un evento en un tema de Kafka. Todas las instancias del Servicio de Redirección y los nodos de caché se suscriben a este tema e invalidan inmediatamente la entrada `short_code` correspondiente. Un TTL corto (ej. 1-5 minutos) en las entradas de caché actúa como respaldo. * **Riesgo 3: Puntos Calientes (Hotspots) en la Base de Datos debido a una distribución desigual de `short_code`:** * *Mitigación:* Para bases de datos SQL distribuidas, confiar en sus capacidades internas de fragmentación y reequilibrio. Para alias personalizados, el alias en sí mismo sirve como clave primaria, lo que debería distribuirse bien. Para códigos cortos generados aleatoriamente, asegurar que el algoritmo de generación produzca códigos suficientemente aleatorios para evitar claves secuenciales que puedan generar puntos calientes. Monitorear las particiones de la base de datos y reequilibrar según sea necesario. 6. Estimación de Capacidad: * **Rendimiento (Throughput):** * **Redirecciones:** 4 mil millones/día = ~46,300 solicitudes/segundo (promedio), pico ~138,900 solicitudes/segundo (3x promedio). * **Creación de Enlaces:** 120 millones/día = ~1,389 solicitudes/segundo (promedio), pico ~4,167 solicitudes/segundo (3x promedio). * **Ingesta de Eventos de Análisis:** ~46,300 eventos/segundo (promedio), pico ~138,900 eventos/segundo. * **Almacenamiento:** * **Datos de Enlaces (Base de Datos SQL Distribuida):** * Tamaño promedio del registro: ~100 bytes (short_code, long_url, timestamps, status, etc.). * Nuevos enlaces diarios: 120 millones * 100 bytes = 12 GB. * Total durante 5 años: 12 GB/día * 365 días/año * 5 años = ~21.9 TB. * Con factor de replicación 3x para alta disponibilidad/multiregión: ~65.7 TB. * **Datos de Análisis (Almacén de Datos):** * Tamaño promedio del evento: ~100 bytes (short_code, timestamp, country, device, referrer). * Eventos diarios: 4 mil millones * 100 bytes = 400 GB. * Total durante 1 año de retención: 400 GB/día * 365 días/año = ~146 TB. * Con factor de replicación 3x: ~438 TB. * **Caché Distribuida (Redis Cluster):** * Cada entrada en caché: `short_code` (ej. 10 bytes) + `long_url` (promedio 500 bytes) = ~510 bytes. * Para almacenar en caché 1 mil millones de enlaces activos (un conjunto de trabajo razonable de enlaces populares): 1 mil millones de enlaces * 510 bytes/enlace = 510 GB de memoria de caché. Este es un tamaño significativo pero manejable para un clúster Redis grande y fragmentado.

## Servicio Global de Acortamiento de URL - Diseño del Sistema ### 1. Arquitectura de Alto Nivel **Componentes Principales:** - **Gateway de API y Balanceador de Carga**: Punto de entrada global con enrutamiento regional (América del Norte, Europa, Asia) - **Servicio de Enlaces Cortos**: Maneja la creación, validación y gestión de alias - **Servicio de Redirección**: Optimizado para redirecciones de alto rendimiento con latencia mínima - **Capa de Caché**: Caché multinivel (CDN de borde, Redis regional, memoria local) - **Almacén de Datos Primario**: Base de datos SQL distribuida (PostgreSQL con sharding) para metadatos de enlaces - **Pipeline de Analítica**: Streaming de eventos (Kafka) → Procesador de streams (Flink/Spark) → Base de datos de analítica (ClickHouse/Druid) - **CDN**: Entrega de contenido global para respuestas de redirección - **Cola de Mensajes**: Para operaciones asíncronas (expiración, eliminación, analítica) - **Monitorización y Observabilidad**: Trazado distribuido, métricas, alertas **Flujos de Solicitud:** *Crear Enlace Corto:* 1. Cliente → Gateway de API (regional) 2. Servicio de Enlaces Cortos valida la entrada, genera un código corto o valida un alias personalizado 3. Comprueba la unicidad del alias en la caché distribuida + base de datos primaria 4. Escribe en la base de datos primaria (con replicación) 5. Invalida la caché, publica evento en Kafka 6. Devuelve el enlace corto (p95 < 300ms) *Redirección (Lectura):* 1. Cliente → Ubicación de borde CDN más cercana 2. CDN comprueba la caché local; si no hay, enruta a la caché regional (Redis) 3. Si la caché regional no tiene, consulta la base de datos primaria con réplica de lectura 4. Respuesta cacheada en el borde de la CDN y Redis regional 5. Devuelve redirección 301/302 (p95 < 80ms) 6. Asíncrono: publica evento de clic en Kafka *Analítica:* 1. Eventos de clic → Tema de Kafka 2. El procesador de streams agrega por link_id, país, dispositivo, referente 3. Escribe métricas agregadas en la base de datos de analítica cada 1-5 minutos 4. El panel consulta la base de datos de analítica para obtener informes --- ### 2. Modelo de Datos y Elecciones de Almacenamiento **Tabla de Metadatos de Enlaces (Base de Datos Primaria - PostgreSQL):** ``` links: - link_id (UUID, clave primaria) - short_code (VARCHAR(10), índice único) - long_url (TEXT, máx. 500 bytes) - user_id (UUID, indexado) - custom_alias (VARCHAR(100), índice único global, nulo) - created_at (TIMESTAMP) - expires_at (TIMESTAMP, nulo, indexado) - is_deleted (BOOLEAN, indexado) - is_custom (BOOLEAN) - created_region (VARCHAR(10)) - metadata (JSONB: título, descripción, etiquetas) ``` **Tabla de Eventos de Analítica (Base de Datos de Series Temporales - ClickHouse):** ``` click_events: - event_id (UUID) - link_id (UUID, indexado) - timestamp (DateTime) - country (VARCHAR(2)) - device_type (VARCHAR(20)) - referrer_domain (VARCHAR(255)) - user_agent (VARCHAR(500)) - ip_hash (VARCHAR(64)) ``` **Justificación de las Elecciones de Almacenamiento:** - **PostgreSQL (Primario)**: Garantías ACID para la creación de enlaces, consistencia fuerte para la unicidad de alias, probado a escala con sharding adecuado - **Redis (Caché Regional)**: Latencia sub-milisegundo para enlaces populares, soporta TTL para expiración automática, distribuido entre regiones - **ClickHouse (Analítica)**: Optimizado para analítica de series temporales, el almacenamiento columnar reduce el almacenamiento de 10x a 100x, agregaciones rápidas - **CDN (Cloudflare/Akamai)**: Caché global en el borde, reduce la latencia a <80ms p95, descarga el tráfico del origen - **Kafka (Stream de Eventos)**: Desacopla la analítica de la ruta de redirección, permite la repetición, soporta múltiples consumidores --- ### 3. Estrategia de Escalado para Tráfico Intensivo de Lectura **Arquitectura de Caché (Multinivel):** 1. **Caché CDN de Borde** (Nivel 1): - Cachea respuestas de redirección globalmente - TTL: 24 horas para enlaces activos, 5 minutos para enlaces expirados - Clave de caché: short_code - Objetivo de ratio de aciertos: 95%+ - Reduce el tráfico del origen en un 95% 2. **Cluster Regional de Redis** (Nivel 2): - 3 regiones: us-east, eu-west, ap-southeast - Cada región: cluster de Redis con 6 nodos (3 primarios, 3 réplicas) - Replicación entre zonas de disponibilidad - TTL: 1 hora para enlaces, 5 minutos para enlaces expirados - Capacidad: 500 GB por región (solo enlaces populares) 3. **Caché Local en Memoria** (Nivel 3): - Caché LRU por instancia de servicio (100 MB) - Reduce los viajes de ida y vuelta a Redis para el 1% de los enlaces más populares **Estrategia de Réplicas de Lectura:** - Base de datos primaria en us-east (maestro de escritura) - Réplicas de lectura en eu-west, ap-southeast (replicación asíncrona, ~100ms de latencia) - Enruta las lecturas a la réplica más cercana - Fallback a la primaria si la réplica no está disponible **Escalado Horizontal:** - Servicio de Redirección: Escalado automático a más de 1000 instancias en todas las regiones - Cada instancia maneja ~4 millones de redirecciones/día (4 mil millones / 1000) - El balanceador de carga distribuye según latencia y capacidad **Generación de Códigos Cortos:** - Codificación Base62 (0-9, a-z, A-Z) para códigos de 6 caracteres - 62^6 = 56 mil millones de códigos posibles (suficiente para 120 millones/día durante más de 400 años) - Generador de IDs distribuido (similar a Snowflake) con prefijo de región para evitar colisiones - Asignación por lotes: cada instancia de servicio preasigna 10K códigos --- ### 4. Estrategia de Fiabilidad **Failover y Alta Disponibilidad:** - **Despliegue multirregional**: Activo-activo en 3 regiones - **Replicación de base de datos**: Replicación de streaming de PostgreSQL con failover automático (Patroni) - **Circuit breakers**: Previenen fallos en cascada cuando la caché/BD no está disponible - **Degradación elegante**: Si la base de datos de analítica está caída, aún se sirven redirecciones; se ponen en cola los eventos localmente **Decisiones de Consistencia:** - **Consistencia fuerte para escrituras**: La creación de enlaces utiliza bloqueos distribuidos (Redis/Zookeeper) para la unicidad de alias - **Consistencia eventual para lecturas**: Las respuestas de redirección pueden estar desactualizadas en ~100ms (aceptable) - **Consistencia eventual para analítica**: Ventana de 5 minutos aceptable según los requisitos - **Manejo de expiración**: Eliminación perezosa (comprueba expires_at en la lectura) + trabajo en segundo plano (escaneo cada hora) **Manejo de Fallos Regionales:** 1. **Detectar fallo**: Las comprobaciones de estado fallan durante 30 segundos 2. **Failover**: Enrutar el tráfico a otras regiones 3. **Operaciones de escritura**: Redirigir a la región primaria (us-east) con fallback a la región local 4. **Operaciones de lectura**: Usar réplicas de lectura en otras regiones 5. **Recuperación**: Sincronizar datos del primario cuando la región se recupera 6. **Monitorización**: Alerta sobre indisponibilidad de región, seguimiento de eventos de failover **Mitigaciones Específicas:** - **Fallo de base de datos**: Failover automático de Patroni a réplica (RTO < 30s) - **Fallo de caché**: Bypass a la BD con limitación de tasa para prevenir thundering herd - **Fallo de CDN**: Dirigir tráfico a la caché regional - **Partición de red**: Asumir que la partición se cura; usar decisiones basadas en quorum - **Corrupción de datos**: Recuperación punto a punto a partir de copias de seguridad (instantáneas diarias) --- ### 5. Compromisos Clave, Cuellos de Botella y Riesgos **Compromisos:** 1. **Consistencia vs. Latencia**: Se eligió consistencia eventual para la analítica para mantener la latencia de redirección <80ms. La consistencia fuerte para la unicidad de alias añade ~50ms pero es necesaria para la corrección. 2. **TTL de Caché vs. Frescura**: El TTL de 24 horas de la CDN reduce la carga del origen, pero significa que los enlaces expirados pueden redirigir hasta por 24 horas. Mitigado por TTL de 5 minutos para enlaces marcados como eliminados. 3. **Almacenamiento vs. Velocidad de Consulta**: Desnormalizar datos de analítica (almacenar país, dispositivo en la tabla de eventos) para permitir agregaciones rápidas, aceptando un sobrecoste de almacenamiento de 2-3x. 4. **Autonomía Regional vs. Consistencia Global**: Cada región puede servir lecturas de forma independiente, pero las escrituras deben coordinarse para la unicidad de alias, añadiendo latencia. **Cuellos de Botella:** 1. **Comprobación de Unicidad de Alias**: Se requiere un bloqueo distribuido global; puede convertirse en un punto de contención durante escrituras pico. Mitigación: Usar Redis con scripts Lua para comprobación y establecimiento atómicos; sharding por el primer carácter del alias. 2. **Rendimiento de Escritura en Base de Datos**: 120 millones de enlaces nuevos/día = ~1400 escrituras/segundo. PostgreSQL puede manejar ~10K escrituras/segundo por instancia, por lo que se necesitan 1-2 instancias primarias. Mitigación: Agrupar escrituras, usar agrupación de conexiones (PgBouncer). 3. **Pipeline de Analítica**: 4 mil millones de clics/día = ~46K eventos/segundo. Kafka puede manejar esto, pero la agregación puede retrasarse. Mitigación: Usar procesador de streams (Flink) para agregación en tiempo real; escribir en la base de datos de analítica cada 1 minuto. **Tres Riesgos Principales y Mitigaciones:** **Riesgo 1: Cache Stampede en la Expiración de Enlaces Populares** - *Escenario*: Un enlace viral con 1 millón de clics/hora expira; todas las entradas de caché se invalidan simultáneamente; 1 millón de solicitudes golpean la BD - *Impacto*: Sobrecarga de la BD, latencia de redirección aumenta a segundos, incumplimiento del SLA - *Mitigación*: - Usar expiración temprana probabilística: actualizar la caché 5 minutos antes de la expiración real - Implementar coalescencia de solicitudes: si múltiples solicitudes golpean un enlace expirado, solo la primera consulta la BD - Establecer tasa máxima de consulta a la BD con circuit breaker; devolver 404 si se excede - Precalentar la caché para enlaces que se sabe que expirarán **Riesgo 2: Colisión de Alias Distribuido bajo Partición de Red** - *Escenario*: Partición de red entre regiones; dos usuarios crean el mismo alias personalizado en regiones diferentes; la partición se cura; conflicto de datos - *Impacto*: Se viola la unicidad del alias; un enlace se vuelve inaccesible; inconsistencia de datos - *Mitigación*: - Usar bloqueo distribuido global (Zookeeper/etcd) para escrituras de alias; fallar si el bloqueo no está disponible - Implementar resolución de conflictos: ganador basado en timestamp (gana la escritura anterior) - Trabajo de auditoría: escanear alias duplicados diariamente; alertar sobre conflictos - Requerir que las escrituras de alias pasen solo por la región primaria (aceptar mayor latencia) **Riesgo 3: Pérdida de Datos de Analítica Durante Fallo del Procesamiento de Streams** - *Escenario*: El consumidor de Kafka se bloquea; los eventos no se procesan; el retraso de la analítica crece; la memoria se llena; los eventos se descartan - *Impacto*: Recuentos de clics inexactos; métricas de negocio no fiables; pérdida de confianza del cliente - *Mitigación*: - Usar grupos de consumidores de Kafka con gestión de offsets; reanudar desde el último offset confirmado - Implementar cola de mensajes fallidos (dead-letter queue) para eventos fallidos; repetir manualmente - Establecer límites de memoria en el búfer de eventos local; descartar los eventos más antiguos si está lleno (con alertas) - Doble escritura de analítica: Kafka → Procesador de streams Y escrituras directas a la BD (con deduplicación) - Monitorizar el retraso del consumidor; alertar si el retraso > 5 minutos --- ### 6. Estimaciones de Capacidad **Almacenamiento:** *Metadatos de Enlaces (PostgreSQL):* - 120 millones de enlaces nuevos/día × 365 días = 43.8 mil millones de enlaces/año - Por enlace: 50 bytes (IDs, timestamps, flags) + 500 bytes (URL larga) + 100 bytes (metadatos) = 650 bytes - Año 1: 43.8 mil millones × 650 B = 28.5 TB - Con retención de 3 años: 85.5 TB - Con replicación (3x): 256.5 TB - Shardeado en 10 instancias: 25.6 TB por instancia (manejable) *Eventos de Analítica (ClickHouse):* - 4 mil millones de clics/día × 365 días = 1.46 billones de eventos/año - Por evento: 50 bytes (IDs, timestamps) + 100 bytes (país, dispositivo, referente) = 150 bytes - Año 1: 1.46 billones × 150 B = 219 TB (sin comprimir) - Compresión ClickHouse: 10-20x → 11-22 TB/año - Retención de 3 años: 33-66 TB (aceptable) *Caché (Redis):* - Enlaces populares (1% del total): 438 millones de enlaces - Por enlace en caché: 50 bytes (short_code, puntero a long_url) = 50 bytes - 438 millones × 50 B = 22 GB por región - 3 regiones: 66 GB total (cabe en la asignación de 500 GB por región) **Rendimiento:** *Rendimiento de Escritura:* - 120 millones de enlaces/día ÷ 86,400 segundos = 1,389 escrituras/segundo - PostgreSQL: 1 instancia primaria maneja 10K escrituras/segundo → 1 instancia suficiente - Kafka: 1,389 eventos/segundo → 1 partición suficiente (Kafka maneja 100K+ msgs/segundo por partición) *Rendimiento de Lectura:* - 4 mil millones de redirecciones/día ÷ 86,400 segundos = 46,296 lecturas/segundo - Pico (3x): 138,888 lecturas/segundo - Tasa de aciertos de caché CDN: 95% → 6,944 lecturas/segundo al origen - Tasa de aciertos de Redis: 99% de las no encontradas → 70 lecturas/segundo a la BD - PostgreSQL: 1 réplica de lectura por región maneja 10K lecturas/segundo → 1 réplica por región suficiente - Instancias de Servicio de Redirección: 46K lecturas/segundo ÷ 100 lecturas/segundo por instancia = 460 instancias (base); 1,389 instancias en pico *Rendimiento de Analítica:* - 4 mil millones de clics/día = 46,296 eventos/segundo - Kafka: 1 tema, 10 particiones (paralelismo) - Procesador de streams: 10 instancias, cada una maneja 4,630 eventos/segundo - ClickHouse: Inserciones por lotes cada 1 minuto; 46K eventos/minuto = manejable **Ancho de Banda de Red:** *Respuestas de Redirección:* - 46K redirecciones/segundo × 300 bytes (respuesta HTTP) = 13.8 MB/segundo - Pico: 41.4 MB/segundo - CDN absorbe el 95% → 2.1 MB/segundo al origen en pico - Fácilmente manejable por conexión de 1 Gbps *Eventos de Analítica:* - 46K eventos/segundo × 500 bytes = 23 MB/segundo - Cluster Kafka: capacidad de 10 Gbps → suficiente **Tabla Resumen:** | Componente | Capacidad | Instancias | Notas | |---|---|---|---| | PostgreSQL Primario | 10K escrituras/seg | 1 | Shardeado para crecimiento futuro | | Réplicas de Lectura PostgreSQL | 10K lecturas/seg | 3 (1 por región) | Replicación asíncrona | | Clusters Redis | 100K ops/seg | 3 (1 por región) | 6 nodos cada uno | | Servicio de Redirección | 100 redirecciones/seg | 460 (base), 1,389 (pico) | Escalado automático | | Brokers Kafka | 100K msgs/seg | 3 | Factor de replicación 3 | | Procesadores de Streams | 4,630 eventos/seg | 10 | Flink/Spark | | Nodos ClickHouse | 1M inserciones/seg | 3 | Cluster distribuido | | Ubicaciones de Borde CDN | Global | 200+ | Cloudflare/Akamai | --- ### Prioridades de Implementación 1. **Fase 1** (MVP): Una sola región, PostgreSQL + Redis + CDN, analítica básica 2. **Fase 2** (Escalado): Multirregional, réplicas de lectura, pipeline de analítica Kafka 3. **Fase 3** (Optimización): Generación de IDs distribuida, caché avanzada, analítica ClickHouse 4. **Fase 4** (Fortalecimiento): Circuit breakers, ejercicios de chaos engineering, simulacros de recuperación ante desastres