Diseñar un servicio de acortamiento de URL

## Diseño del Sistema: Servicio de Acortamiento de URL ### A. Arquitectura de Alto Nivel El sistema constará de los siguientes componentes principales: 1. **Balanceadores de Carga (LBs):** Distribuyen el tráfico entrante (tanto las solicitudes de API para acortar como las solicitudes de redirección) entre múltiples servidores de API. Utilizaremos varias capas de LBs, comenzando con un LB global (por ejemplo, AWS Route 53) para el enrutamiento basado en DNS y luego LBs regionales (por ejemplo, AWS ELB/ALB) para distribuir el tráfico dentro de una región. 2. **Servidores de API (Servidores Web):** Manejan las solicitudes entrantes tanto para crear URL cortas (POST /shorten) como para redirigir URL cortas (GET /{short_code}). Estos servidores no tendrán estado. 3. **Servicio de Acortamiento de URL (Lógica de Negocio):** Un microservicio responsable de generar códigos cortos, interactuar con la base de datos y potencialmente almacenar en caché. 4. **Base de Datos:** Almacena la correspondencia entre los códigos cortos y las URL originales. Discutiremos la elección en detalle en la sección C. 5. **Caché:** Almacena las correspondencias de URL cortas accedidas con frecuencia para reducir la carga de la base de datos y la latencia de las redirecciones. Se utilizará Redis o Memcached. 6. **Cola de Mensajes (Opcional pero recomendada para escala):** Para el procesamiento asíncrono de tareas como la actualización de análisis o el manejo de posibles reintentos, aunque no es estrictamente necesaria para la funcionalidad principal. **Flujo de Solicitudes:** * **Creación de URL (POST /shorten):** 1. El cliente envía una solicitud POST con la URL original a la Puerta de Enlace de API/Balanceador de Carga. 2. El LB reenvía la solicitud a un Servidor de API disponible. 3. El Servidor de API llama al Servicio de Acortamiento de URL. 4. El Servicio de Acortamiento de URL genera un código corto único (ver sección B). 5. El servicio almacena la correspondencia (short_code -> original_url) en la Base de Datos. 6. El servicio también podría escribir la correspondencia en la Caché. 7. El Servidor de API devuelve la URL acortada (por ejemplo, `https://short.url/{short_code}`) al cliente. * **Redirección de URL (GET /{short_code}):** 1. El usuario introduce una URL acortada en su navegador. 2. La solicitud llega al Balanceador de Carga. 3. El LB reenvía la solicitud a un Servidor de API disponible. 4. El Servidor de API (o un Servicio de Redirección dedicado) primero verifica la Caché en busca del `short_code`. 5. **Acertada en Caché:** Si se encuentra, la URL original se recupera de la caché y el Servidor de API emite una respuesta HTTP 301 (Redirección Permanente) o 302 (Redirección Temporal) al cliente con la URL original. 6. **Fallo en Caché:** Si no se encuentra en la caché, el Servidor de API consulta la Base de Datos en busca del `short_code`. 7. La Base de Datos devuelve la URL original. 8. El Servidor de API agrega la correspondencia a la Caché para futuras solicitudes. 9. El Servidor de API emite la respuesta de redirección HTTP. ### B. Estrategia de Generación de URL Cortas Necesitamos una estrategia que genere códigos únicos, cortos y que, preferiblemente, parezcan algo aleatorios. El objetivo principal es la unicidad y la eficiencia. * **Hashing (por ejemplo, MD5, SHA-1):** * *Pros:* Determinista, puede generar códigos únicos. Se puede truncar. * *Contras:* Son posibles colisiones (aunque raras con buen hashing y truncamiento). Los códigos podrían no estar distribuidos uniformemente, lo que llevaría a puntos calientes. No son fácilmente legibles por humanos ni memorables. * **Basado en Contador (por ejemplo, ID autoincremental):** * *Pros:* Garantiza la unicidad. Sencillo de implementar. * *Contras:* El contador centralizado puede convertirse en un cuello de botella. Los IDs secuenciales son predecibles y pueden revelar patrones de uso. Requiere un sistema de contador distribuido para alta disponibilidad y escala. * **Pools de Claves Pre-generados:** * *Pros:* Distribuye la carga de generación. Puede pre-generar un gran pool de códigos únicos. * *Contras:* Requiere administrar el pool, asegurar que no haya solapamientos y potencialmente pre-generar una gran cantidad de claves. * **Codificación Base-62/Base-64 de un Contador:** * *Pros:* Genera códigos cortos y únicos codificando un contador monotónicamente creciente (por ejemplo, un entero de 64 bits) en un alfabeto base-62 (0-9, a-z, A-Z) o base-64. Esto es eficiente y produce cadenas relativamente cortas. Garantiza la unicidad si el contador se gestiona correctamente. * *Contras:* Requiere un servicio de contador distribuido para evitar cuellos de botella y garantizar la unicidad entre múltiples servidores de API. **Estrategia Elegida: Codificación Base-62 de un Contador Distribuido** Este enfoque ofrece el mejor equilibrio entre unicidad, brevedad y escalabilidad. Utilizaremos un servicio de generación de IDs distribuidos (como Snowflake de Twitter o Apache ZooKeeper) para generar IDs únicos y secuenciales de 64 bits. Cada ID se codificará luego en una cadena base-62. Esto proporciona códigos cortos y únicos. La naturaleza secuencial de los IDs se puede gestionar para evitar patrones predecibles utilizando un componente aleatorio en la generación del ID o barajando la correspondencia más tarde. ### C. Almacenamiento de Datos **Tecnología de Base de Datos:** Una base de datos NoSQL como **Cassandra** o **ScyllaDB** (una base de datos compatible con Cassandra de alto rendimiento) es un candidato fuerte debido a su naturaleza distribuida, alta disponibilidad y excelente rendimiento de escritura, que es crucial para la creación de URL. Alternativamente, una base de datos relacional fragmentada (como PostgreSQL con Citus o MySQL con Vitess) podría funcionar, pero NoSQL a menudo simplifica la escalabilidad para este tipo de búsqueda de clave-valor. Asumamos **Cassandra** por su escalabilidad lineal y tolerancia a fallos. **Esquema:** Utilizaremos un esquema simple en un keyspace optimizado para lecturas: ```cql CREATE TABLE url_mappings ( short_code text PRIMARY KEY, original_url text, created_at timestamp ); ``` * `short_code`: El código corto único generado (por ejemplo, `aBcDeF`). Esta es la clave primaria. * `original_url`: La URL larga a la que redirigir. * `created_at`: Marca de tiempo de cuándo se acortó la URL. **Estimación de Requisitos de Almacenamiento (durante 5 años):** * **Nuevas URL por mes:** 100 millones * **Total de URL durante 5 años:** 100 millones/mes * 12 meses/año * 5 años = 6 mil millones de URL * **Longitud promedio del código corto:** La codificación Base-62 de un entero de 64 bits da como resultado aproximadamente 11 caracteres. Supongamos 15 bytes para el `short_code` (incluyendo sobrecarga). * **Longitud promedio de la URL original:** Supongamos 2000 bytes (las URL pueden ser muy largas). * **Sobrecarga:** Supongamos un 10% de sobrecarga para el almacenamiento de la base de datos (replicación, índices, etc.). **Almacenamiento Total:** (6 mil millones de URL) * (15 bytes/short_code + 2000 bytes/original_url) * 1.10 (sobrecarga) = 6 * 10^9 * 2015 bytes * 1.10 ≈ 13.3 * 10^12 bytes ≈ 13.3 Terabytes (TB) Esta es una cantidad manejable para una base de datos NoSQL distribuida como Cassandra, que puede escalar horizontalmente añadiendo más nodos. **¿Por qué Cassandra?** * **Escalabilidad:** Escala linealmente añadiendo más nodos, manejando cantidades masivas de datos y tráfico. * **Disponibilidad:** Diseñada para alta disponibilidad sin un único punto de fallo. Los datos se replican en múltiples nodos y centros de datos. * **Rendimiento de Escritura:** Excelente rendimiento de escritura, crucial para la parte de creación de URL. * **Rendimiento de Lectura:** Puede optimizarse para búsquedas rápidas de clave-valor, que es lo que requiere la redirección. ### D. Estrategia de Escalado **1. Estrategia de Caché:** * **Caché de Nivel 1 (Caché Distribuida):** Utilizar un clúster de Redis o Memcached. Almacenar las correspondencias `short_code -> original_url`. Esto servirá a la gran mayoría de las solicitudes de lectura (el 99% del tráfico, dada la relación de lectura/escritura de 100:1). * **Invalidación/Expiración de Caché:** Para simplificar y dada la vida útil de 5 años, podemos usar un Tiempo de Vida (TTL) ligeramente superior al patrón de acceso esperado, o simplemente confiar en el hecho de que una vez que se crea una URL corta, su correspondencia rara vez cambia. Una estrategia común es almacenar en caché indefinidamente hasta que la aplicación se reinicie o se active una invalidación manual (aunque esto es menos común para los acortadores de URL). * **Población de Caché:** Cuando una solicitud de redirección no encuentra la caché, la URL original se recupera de la base de datos y luego se escribe en la caché antes de devolver la redirección. **2. Particionamiento/Fragmentación de Base de Datos:** * **Cassandra:** Cassandra maneja el particionamiento automáticamente basándose en la clave primaria (`short_code`). Los datos se distribuyen entre los nodos utilizando un algoritmo de hashing consistente. Esto fragmenta los datos de forma inherente. * **Base de Datos Relacional (si se elige):** Fragmentar la base de datos basándose en el `short_code` (por ejemplo, utilizando un hash del `short_code` para determinar el fragmento). Esto distribuye la carga y los datos entre múltiples instancias de base de datos. **3. Manejo de Claves Calientes (URL Virales):** * **Caché:** La defensa principal contra las claves calientes es el almacenamiento en caché agresivo. Una URL viral se almacenará en caché intensivamente en Redis/Memcached, lo que significa que las solicitudes posteriores se servirán directamente desde la memoria, evitando la base de datos por completo. * **Réplicas de Lectura de Base de Datos (si se usa RDBMS):** Si la base de datos se convierte en un cuello de botella incluso con caché, se pueden emplear réplicas de lectura, aunque la naturaleza distribuida de Cassandra ya maneja esto bien. * **Red de Entrega de Contenidos (CDN):** Para tráfico extremadamente alto, las respuestas de redirección en sí mismas podrían potencialmente almacenarse en caché en el borde utilizando una CDN, aunque esto añade complejidad y podría no ser adecuado para todos los tipos de redirección (por ejemplo, 302). Sin embargo, los propios servidores de API podrían colocarse detrás de una CDN para un acceso global más rápido. * **Ruta de Lectura Dedicada:** Para casos extremos, se podría considerar una capa de caché o una base de datos separada optimizada para lectura, pero la caché principal debería manejar la mayoría de los escenarios de claves calientes. ### E. Fiabilidad y Tolerancia a Fallos **1. Alta Disponibilidad (99.9% de Tiempo de Actividad):** * **Redundancia:** Desplegar múltiples instancias de cada componente (servidores de API, nodos de caché, nodos de base de datos) en múltiples Zonas de Disponibilidad (AZs) o incluso regiones. * **Balanceadores de Carga:** Los LBs dirigirán automáticamente el tráfico lejos de las instancias no saludables. * **Servidores de API sin Estado:** Los servidores de API no tienen estado, por lo que cualquier servidor puede manejar cualquier solicitud. Si uno falla, otros toman el relevo sin problemas. * **Replicación de Base de Datos:** Cassandra proporciona replicación de datos incorporada. Configuraremos un factor de replicación (por ejemplo, 3) en múltiples nodos y racks/AZs. Si un nodo falla, las réplicas en otros nodos sirven los datos. * **Replicación/Clustering de Caché:** Redis Sentinel o Redis Cluster pueden proporcionar alta disponibilidad para la caché. **2. Manejo de Fallos de Componentes:** * **Fallo del Servidor de API:** Los LBs detectan el fallo y dejan de enviar tráfico a la instancia no saludable. Otras instancias continúan sirviendo solicitudes. * **Fallo del Nodo de Caché:** Si se utiliza Redis Cluster o Sentinel, el sistema promueve automáticamente una réplica o reconfigura el clúster. Si falla un solo nodo, algunos datos cacheados pueden quedar temporalmente no disponibles, pero el sistema recurrirá a la base de datos. * **Fallo del Nodo de Base de Datos:** Cassandra maneja automáticamente los fallos de nodos. Los datos están disponibles a partir de réplicas en otros nodos. Si falla una AZ completa, los datos siguen estando disponibles en nodos de otras AZs (si el despliegue es multi-AZ). **3. Replicación de Datos y Failover:** * **Base de Datos:** La estrategia de replicación de Cassandra garantiza la durabilidad y disponibilidad de los datos. Utilizaremos un factor de replicación de 3, con réplicas distribuidas en diferentes ubicaciones físicas (racks/AZs). Si falla un nodo, las lecturas y escrituras aún pueden ser atendidas por otras réplicas. * **Caché:** Redis Sentinel o Cluster proporciona failover automático para los nodos de caché. * **Nivel de Aplicación:** Implementar mecanismos de reintento para problemas de red transitorios al comunicarse entre servicios. ### F. Principales Compensaciones (Trade-offs) 1. **Consistencia vs. Disponibilidad (Teorema CAP):** * **Elección:** Priorizamos la **Disponibilidad** y la **Tolerancia a Particiones** sobre la Consistencia Fuerte para el servicio de redirección. Para la creación de URL, necesitamos consistencia fuerte para garantizar códigos cortos únicos. Para la redirección, si una réplica de base de datos no está disponible temporalmente, preferiríamos servir una entrada cacheados obsoleta o devolver un error en lugar de bloquear las solicitudes. * **Justificación:** La función principal de un acortador de URL es redirigir a los usuarios de forma rápida y fiable. Las entradas de caché ocasionalmente obsoletas o la indisponibilidad temporal de la correspondencia de una URL corta específica (lo que sería raro con una replicación adecuada) es más aceptable que las interrupciones generalizadas del servicio. Para la creación de URL, se utiliza un generador de IDs distribuido con garantías de consistencia fuerte para asegurar la unicidad. 2. **Latencia vs. Costo/Complejidad (Estrategia de Caché):** * **Elección:** Elegimos una estrategia de caché agresiva y de múltiples capas (caché en memoria como Redis/Memcached) para lograr el requisito de latencia inferior a 50 ms para las redirecciones. * **Justificación:** La relación de lectura/escritura de 100:1 y el estricto requisito de latencia (99.9% de tiempo de actividad, <50 ms de latencia en el percentil 95) hacen que el almacenamiento en caché sea esencial. Servir la mayoría de las solicitudes directamente desde la RAM reduce significativamente la carga de la base de datos y los tiempos de respuesta. Si bien el almacenamiento en caché añade complejidad (invalidez de caché, preocupaciones de consistencia, costo de infraestructura adicional), es una compensación necesaria para cumplir los objetivos de rendimiento y disponibilidad. Sin él, la base de datos se vería abrumada por el tráfico de lectura, lo que provocaría una mayor latencia y posibles interrupciones.

A) Arquitectura de alto nivel Componentes 1) Borde (Edge) - DNS + CDN/Anycast edge (opcional pero muy recomendado para p95 <50ms a nivel global) - WAF + protección DDoS - Balanceadores de carga globales (GSLB) que enrutan a la región más cercana 2) Pila regional (al menos 2 regiones, activo-activo) - Balanceador de carga L7 (ALB/Envoy) - Servicio API sin estado (Acortador de URL) - API de creación (ruta de escritura) - API de redirección (ruta de lectura) - Nivel de caché - Caché L1 en memoria (pequeña, por instancia, claves muy calientes) - Caché distribuida L2 (cluster Redis/Memcached) - Almacenamiento persistente - Almacén KV principal (estilo DynamoDB/Cassandra/ScyllaDB) para mapeo short_code -> long_url - Almacén relacional opcional (Postgres/MySQL) para análisis, cuentas de usuario, alias personalizados (no en la ruta de redirección crítica) - Pipeline asíncrono (no crítico) - Kafka/Kinesis/PubSub para eventos de clics, registros, señales de abuso - Procesadores de flujo / destino OLAP (ClickHouse/BigQuery/S3) Flujo de solicitud: Creación de URL (escritura) 1) El cliente llama a POST /api/shorten con long_url (+ alias personalizado opcional, política TTL, autenticación de usuario). 2) La solicitud llega a GSLB -> balanceador de carga regional -> servidor API. 3) La API valida la URL (formato, listas de permitidos/denegados, navegación segura), la normaliza y aplica límites de velocidad. 4) El servicio de generación de códigos cortos asigna un código único (detalles en la sección B). 5) La API escribe el mapeo en el almacén KV (short_code como clave de partición). - La escritura incluye created_at, expire_at (>=5 años), long_url, owner_id, flags. - Utilizar escritura de quorum (o escritura fuertemente consistente según el almacén). 6) La API rellena la caché L2 con short_code -> long_url (write-through) y devuelve la URL corta. 7) Emitir eventos asíncronos (creado, usuario, puntuación de spam) al stream; no es necesario para la respuesta de éxito. Flujo de solicitud: Redirección de URL (lectura) 1) El navegador solicita GET /{code}. 2) El borde enruta a la región más cercana; la CDN opcional puede almacenar en caché las respuestas 301/302 si la política lo permite. 3) El servidor API analiza el código. 4) Orden de búsqueda: a) Caché L1 en memoria b) Caché L2 Redis/Memcached c) Almacén KV (si hay fallo de caché) 5) Si se encuentra y no ha expirado/bloqueado: devolver redirección HTTP 301/302 con Location: long_url. - Rellenar caché en caso de fallo (establecer en L2; opcionalmente L1). 6) Emitir evento de clic de forma asíncrona (fire-and-forget). 7) Si no se encuentra: 404 (opcionalmente, recurrir a la región de origen si se utiliza aislamiento regional). Objetivos de latencia - El acierto de caché L2 debería dominar (desde sub-milisegundo hasta unos pocos ms dentro de la región). Con enrutamiento de borde + alta tasa de aciertos de caché, es factible <50ms p95. B) Estrategia de generación de URL cortas Requisitos - 100M de acortamientos nuevos/mes ~ 3.3M/día ~ ~38.6 escrituras/segundo en promedio (picos más altos). - Debe generar códigos únicos, cortos y seguros para URL con bajo riesgo de colisión y sin cuello de botella de coordinación. Opciones 1) Hash(long_url) - Pros: determinista; posible deduplicación. - Contras: las colisiones requieren manejo; revela patrones; difícil dar soporte a múltiples URL largas idénticas para diferentes usuarios; el cambio de normalización afecta la estabilidad. 2) Contador central (autoincremental) + codificación base62 - Pros: compacto; sin colisiones; simple. - Contras: cuello de botella lógico único a menos que se divida en fragmentos (sharding); los códigos secuenciales son predecibles (seguridad/abuso). 3) ID distribuido (estilo Snowflake: tiempo + trabajador + secuencia) luego base62 - Pros: sin coordinador central; escalable; único; tamaño limitado. - Contras: códigos ligeramente más largos; el orden basado en el tiempo filtra algo de información. 4) Pool de claves pregeneradas - Pros: asignación más rápida; desacopla la creación de la generación de ID. - Contras: requiere administrar el pool, el almacenamiento y evitar la reutilización; complejidad operativa. Enfoque elegido - Usar un ID único de 64 bits estilo Snowflake generado por cada nodo de API (o servicio de ID dedicado) y codificarlo a base62/base64url. - 64 bits en base62 produce hasta 11 caracteres en el peor de los casos; típicamente 10-11 caracteres, aceptable. - Si se requieren códigos más cortos, usar 56-60 bits (aún suficientes) con una época/ventana de tiempo y bits de trabajador cuidadosamente seleccionados. - Para reducir la predecibilidad, aplicar opcionalmente una permutación reversible (por ejemplo, red Feistel) al ID de 64 bits antes de la codificación base62; mantiene la unicidad pero hace que los códigos no sean secuenciales. Por qué esta elección - Elimina el cuello de botella del contador único. - No se necesita manejo de colisiones. - Funciona bien con multi-región activo-activo. - La predecibilidad se mitiga mediante la permutación. Alias personalizados - Si el usuario solicita un código personalizado, validar la disponibilidad con una escritura condicional (put-if-absent) en el almacén KV; si hay conflicto, rechazar. C) Almacenamiento de datos Elección de base de datos - Almacén principal: una base de datos KV altamente disponible y escalable horizontalmente (DynamoDB o Cassandra/ScyllaDB). - Razonamiento: - El patrón de acceso es lectura basada en clave por short_code. - Predominantemente lectura con alto QPS; los almacenes KV sobresalen en búsquedas puntuales de baja latencia. - Replicación, particionamiento y madurez operativa integrados. Esquema (tabla única) Tabla: url_mapping - Clave de partición: short_code (cadena) - Atributos: - long_url (cadena) - created_at (timestamp) - expire_at (timestamp, debe ser >= created_at + 5 años; puede ser nulo para "nunca", pero el requisito dice al menos 5 años) - owner_id (cadena, opcional) - status (activo/deshabilitado/malicioso) - meta (opcional: título, campaña, etc.) Índices (opcional) - GSI/índice secundario en owner_id + created_at para listar enlaces de usuario (no en la ruta de redirección). Estimación de almacenamiento (5 años) - URL nuevas: 100M/mes * 12 * 5 = 6 mil millones de mapeos. - Estimación aproximada del tamaño por registro: - short_code: 10-11 bytes (almacenar como ~16 bytes con sobrecarga) - long_url: asumir un promedio de 100 bytes (podría ser 50-200; usar 120 incluyendo sobrecarga) - timestamps/status/owner_id: ~40 bytes en promedio (owner_id opcional) - Sobrecarga de la BD (claves, metadatos de replicación, compresión): varía; asumir ~100 bytes de sobrecarga - Total lógico por elemento ~250 bytes (conservador) - Almacenamiento lógico bruto: 6e9 * 250B = 1.5 TB. - Con factor de replicación 3 (común en Cassandra/Scylla): ~4.5 TB. - Añadir índices + margen: planificar ~6-10 TB en todo el clúster durante 5 años. Notas - Las URL largas se pueden comprimir (diccionario/deflate) a nivel de aplicación para reducir el tamaño; pero solo si no añade latencia. Muchos almacenes KV también comprimen SSTables. D) Estrategia de escalado Estimación de tráfico - Escrituras: ~38.6/s en promedio; asumir pico 10x => ~400/s. - Lecturas: 100:1 => promedio ~3,860 lecturas/s; pico potencialmente mucho mayor (por ejemplo, 50k-200k/s dependiendo de los picos de uso). Escalado de lecturas 1) Caching - Caché L1 en memoria: pequeña (por ejemplo, 10k-100k entradas) con TTL corto (30-120s) para absorber micro-puntos calientes y reducir el QPS de Redis. - Caché L2 Redis/Memcached: - Valor de caché: long_url + status + expire_at. - Estrategia TTL: - Si los enlaces son inmutables (común), establecer TTL largo (horas a días). - Aún así, respetar expire_at estableciendo TTL = min(max_ttl_configurado, expire_at - ahora). - Usar cache-aside con caché negativa: - Caché "no encontrado" para un TTL corto (por ejemplo, 30-60s) para reducir los accesos a la BD de los escáneres. - Apuntar a una tasa de aciertos de caché >95-99% para redirecciones. 2) Caché CDN (opcional pero potente) - Para redirecciones 301 que son estables, la CDN puede almacenar en caché la respuesta de redirección para códigos populares. - Debe considerar la capacidad de deshabilitar enlaces rápidamente; mitigar mediante: - TTL corto de CDN (por ejemplo, 60-300s) + purga al deshabilitar - O mantener la lógica de redirección en el origen pero almacenar en caché el mapeo en el borde KV (avanzado). Particionamiento/sharding de base de datos - Particionar por short_code (hashing consistente / anillo de tokens). - Se espera una distribución uniforme porque los códigos son pseudoaleatorios (post-permutación). - Añadir nodos para escalar linealmente. Manejo de claves calientes (URL virales) - Enfoque de múltiples capas: 1) Cachés de borde/CDN la respuesta de redirección para las claves más calientes con TTL corto. 2) Las cachés L1 + L2 reducen la carga de la BD de origen. 3) Escalado del clúster Redis: dividir por clave; habilitar hashing del lado del cliente. 4) Coalescencia de solicitudes / vuelo único en fallo de caché: si muchas solicitudes fallan simultáneamente para la misma clave, una solicitud rellena la caché mientras otras esperan brevemente. 5) Para casos extremos, permitir la "replicación de claves calientes" en caché (almacenar la misma clave en múltiples fragmentos) o usar un nivel de "caché caliente" dedicado. Escalado de escrituras - Las escrituras son modestas; asegurar escrituras condicionales para unicidad e idempotencia. - Usar limitación de velocidad y prevención de abuso para evitar la amplificación de escrituras por bots. E) Fiabilidad y tolerancia a fallos (99.9% de tiempo de actividad) Multi-región - Activo-activo en al menos 2 regiones. - Las comprobaciones de estado de GSLB desvían el tráfico de la región no saludable. Servicios sin estado - Los servidores API no tienen estado; escalan horizontalmente; se implementan en múltiples AZ. Nivel de caché - Redis/Memcached implementado como un clúster fragmentado con réplicas por fragmento (o Redis Cluster con réplicas). - Si la caché falla: el sistema recurre a la BD; mayor latencia pero aún funcional. - Proteger la BD con disyuntores y limitación de velocidad adaptativa si la interrupción de la caché causa una estampida. Replicación y conmutación por error de la base de datos - Opción DynamoDB: - Usar Tablas Globales para replicación activo-activo multi-región. - Configurar capacidad bajo demanda o aprovisionada con escalado automático. - Opción Cassandra/Scylla: - Replicación multi-AZ dentro de la región (RF=3). - Replicación multi-región a través de NetworkTopologyStrategy; ajustar la consistencia (por ejemplo, LOCAL_QUORUM para lecturas/escrituras) para mantener baja la latencia. - Modos de fallo: - Fallo de un solo nodo: las lecturas/escrituras de réplica continúan. - Fallo de AZ: las AZ restantes atienden el tráfico (RF entre AZ). - Fallo de región: GSLB cambia a la región saludable; datos disponibles a través del almacén replicado. Durabilidad de los datos - Copias de seguridad/instantáneas regulares en almacenamiento de objetos (S3/GCS) + recuperación a nivel de punto en el tiempo. - Simulacros de recuperación ante desastres y pruebas de restauración. Seguridad de la implementación - Despliegues continuos (rolling deployments) + lanzamientos canarios. - Banderas de funcionalidades (feature flags). - Reversión automática ante el agotamiento del presupuesto de errores. Controles operativos - SLI: latencia p95 de redirección, tasa de aciertos de caché, p95 de BD, tasa de error, latencia de replicación. - SLO: 99.9% de disponibilidad; diseño para degradación elegante (por ejemplo, deshabilitar temporalmente las escrituras de análisis). F) Compensaciones clave 1) Cortedad del código vs generación distribuida - Compensación: Un contador centralizado puede producir códigos muy cortos (a menudo 6-8 caracteres al principio), pero añade coordinación y es más difícil en multi-región. - Elección: IDs distribuidos estilo Snowflake + base62 (10-11 caracteres) para garantizar escalabilidad, unicidad y compatibilidad multi-región, cumpliendo al mismo tiempo los requisitos de latencia/disponibilidad. 2) Consistencia fuerte vs baja latencia/alta disponibilidad - Compensación: Las lecturas globales fuertemente consistentes aumentan la latencia y reducen la disponibilidad durante las particiones. - Elección: usar quorum local/consistencia local de región para las búsquedas de redirección (rápido) con replicación multi-región. Para las operaciones de creación, garantizar la unicidad con escrituras condicionales y aceptar la propagación eventual entre regiones; las redirecciones siguen siendo correctas porque el mapeo autoritativo existe en al menos una región y se replica rápidamente. 3) Caching agresivo vs respuesta rápida de deshabilitación/abuso - Compensación: Los TTL largos de caché mejoran la latencia y reducen la carga de la BD, pero dificultan la deshabilitación inmediata de enlaces maliciosos. - Elección: TTL moderados + mecanismos de purga, además de comprobaciones de estado en el valor almacenado en caché y TTL corto para CDN; permitir el "interruptor de apagado" almacenando en caché el estado deshabilitado con alta prioridad. Resumen - Usar enrutamiento de borde + caché intensiva para mantener las redirecciones por debajo de 50ms p95. - Usar generación de ID única distribuida (Snowflake + permutación) para la generación escalable de códigos. - Almacenar mapeos en un almacén KV replicado con sharding por short_code y conmutación por error multi-región. - Mantener un tiempo de actividad del 99.9% a través de multi-AZ + multi-región, servicios sin estado, almacenamiento replicado y rutas de degradación elegante.