Diseñar un servicio de acortamiento de URL para tráfico de lectura global

## Diseño de Servicio de Acortamiento de URL ### 1. Arquitectura de Alto Nivel y Componentes Principales El sistema estará compuesto por varios microservicios, desplegados en múltiples zonas de disponibilidad y regiones para alta disponibilidad y baja latencia. * **API Gateway:** Maneja las solicitudes entrantes, autenticación, limitación de velocidad y enruta las solicitudes a los servicios apropiados. * **Servicio de Creación de Enlaces:** Responsable de generar URL cortas, almacenarlas y manejar alias personalizados. Interactúa con el Servicio de Generación de ID y la Base de Datos de Metadatos. * **Servicio de Resolución de Enlaces:** Maneja las solicitudes de redirección entrantes. Obtiene la URL larga de la caché o la base de datos y realiza la redirección. También registra eventos de clics. * **Servicio de Analíticas:** Procesa los registros de clics, agrega datos y proporciona informes de analíticas. * **Servicio de Generación de ID:** Genera ID cortos únicos para las URL. Este puede ser un servicio separado y de alta disponibilidad. * **Servicio de Registro de Clics:** Un servicio de alto rendimiento responsable de ingerir eventos de clics brutos. * **Interfaz Web/Panel de Administración:** Para que los usuarios creen enlaces, los administren y vean analíticas. **Diagrama de Arquitectura (Conceptual):** ``` +-----------------+ +-----------------+ +-----------------------+ | Load Balancer |----->| API Gateway |----->| Link Creation Service | +-----------------+ +-----------------+ +-----------------------+ | | (Redirects) v +-----------------+ +-----------------+ +-----------------------+ | Load Balancer |----->| Link Resolution | +-----------------+ | Service | +-----------------+ | | (Click Events) v +-----------------------+ | Click Logging Service | +-----------------------+ | | (Raw Logs) v +-----------------------+ | Message Queue | +-----------------------+ | | (Processed Data) v +-----------------------+ | Analytics Service | +-----------------------+ | | (Analytics Data) v +-----------------------+ | Analytics Database | +-----------------------+ **Bases de Datos:** * **Base de Datos de Metadatos:** Almacena mapeos de URL corta a URL larga, alias personalizados, marcas de tiempo de creación, tiempos de expiración e información del usuario. * **Base de Datos de Analíticas:** Almacena datos de clics agregados por enlace. * **Base de Datos/Servicio de Generación de ID:** Para generar ID únicos. **Caché:** * **Caché de Lectura:** Para URL cortas accedidas frecuentemente para acelerar las redirecciones. **Cola/Stream de Mensajes:** * Para desacoplar el registro de clics de la ruta de redirección y permitir el procesamiento asíncrono para analíticas. ``` ### 2. Modelo de Datos Central y Opciones de Almacenamiento **Base de Datos de Metadatos:** * **Elección:** Una base de datos NoSQL distribuida como Cassandra o una base de datos relacional fragmentada (por ejemplo, PostgreSQL con Citus) para escalabilidad y disponibilidad. * **Esquema:** * `links` tabla/colección: * `short_id` (cadena, clave primaria): El identificador corto único. * `long_url` (cadena): La URL larga original. * `user_id` (cadena, opcional): Identificador del usuario que creó el enlace. * `created_at` (marca de tiempo): Cuándo se creó el enlace. * `expires_at` (marca de tiempo, opcional): Cuándo expira el enlace. * `custom_alias` (cadena, opcional, índice único): Alias definido por el usuario. * `updated_at` (marca de tiempo, opcional): Hora de la última actualización (para la ventana de actualización de 10 minutos). * `destination_updated_at` (marca de tiempo, opcional): Marca de tiempo de la última actualización de la URL de destino. **Base de Datos de Analíticas:** * **Elección:** Una base de datos de series temporales (por ejemplo, InfluxDB, TimescaleDB) o un almacén de datos (por ejemplo, Snowflake, BigQuery) para una agregación y consulta eficientes de datos basados en el tiempo. * **Esquema:** * `click_analytics` tabla/colección: * `short_id` (cadena, indexado). * `timestamp` (marca de tiempo, indexado). * `country_code` (cadena, opcional). * `device_type` (cadena, opcional). * `aggregated_count` (entero): Para datos pre-agregados. **Generación de ID:** * **Elección:** Un servicio dedicado de generación de ID distribuido (por ejemplo, usando el algoritmo Snowflake o una secuencia de base de datos con un servicio dedicado). Esto garantiza la unicidad y alta disponibilidad. **Registros de Clics:** * **Elección:** Una cola de mensajes de alto rendimiento (por ejemplo, Kafka, AWS Kinesis) para almacenar temporalmente eventos de clics brutos antes de que sean procesados por el Servicio de Analíticas. ### 3. Diseño de API **URL Base:** `https://short.url/api/v1` **1. Crear Enlace:** * **Endpoint:** `POST /links` * **Cuerpo de la Solicitud:** ```json { "long_url": "https://example.com/very/long/url", "custom_alias": "my-custom-alias" // Opcional "expires_at": "2023-12-31T23:59:59Z" // Opcional } ``` * **Cuerpo de la Respuesta:** ```json { "short_url": "https://short.url/xyz123", "long_url": "https://example.com/very/long/url", "custom_alias": "my-custom-alias" // Si se proporcionó } ``` **2. Resolver Enlace (Redirección):** * **Endpoint:** `GET /{short_id}` o `GET /{custom_alias}` * **Lógica:** El Servicio de Resolución de Enlaces manejará esto. Buscará el `short_id` o `custom_alias` primero en la caché. Si no se encuentra, consulta la Base de Datos de Metadatos. Después de obtener la `long_url`, registra el evento de clic y devuelve un 301 (Redirección Permanente) o 302 (Redirección Temporal) a la `long_url`. * **Prevención de Abuso:** Se pueden realizar verificaciones básicas de patrones maliciosos conocidos o URL en listas negras aquí. **3. Obtener Analíticas de Enlace:** * **Endpoint:** `GET /links/{short_id}/analytics` * **Parámetros de Consulta:** * `start_time` (marca de tiempo, requerido) * `end_time` (marca de tiempo, requerido) * `group_by` (cadena, opcional, por ejemplo, "day", "country") * **Cuerpo de la Respuesta:** ```json { "short_id": "xyz123", "total_clicks": 1500, "clicks_over_time": [ {"timestamp": "2023-10-27T10:00:00Z", "count": 50}, {"timestamp": "2023-10-27T11:00:00Z", "count": 75} ], "clicks_by_country": [ {"country": "US", "count": 1000}, {"country": "EU", "count": 500} ] } ``` **4. Actualizar Destino del Enlace (dentro de los 10 minutos posteriores a la creación):** * **Endpoint:** `PUT /links/{short_id}` * **Cuerpo de la Solicitud:** ```json { "long_url": "https://new.example.com/updated/url" } ``` * **Respuesta:** 200 OK o error. ### 4. Estrategia de Escalado * **Tráfico de Lectura (Redirecciones):** * **Caché:** Almacenar agresivamente los mapeos de `short_id` a `long_url` en una caché distribuida (por ejemplo, Redis, Memcached) con un TTL corto (por ejemplo, 5-10 minutos) para manejar ráfagas. Las fallas de caché golpearán la base de datos. * **Fragmentación de Base de Datos:** La Base de Datos de Metadatos se fragmentará por `short_id` o un hash del mismo para distribuir la carga. * **Réplicas de Lectura:** Usar réplicas de lectura para la Base de Datos de Metadatos para descargar el tráfico de lectura. * **Distribución Global:** Desplegar instancias del Servicio de Resolución de Enlaces en múltiples regiones cercanas a los usuarios. Usar GeoDNS para enrutar a los usuarios a la región más cercana. * **Tráfico de Escritura (Creación de Enlaces):** * **Servicios sin Estado:** Las instancias del Servicio de Creación de Enlaces deben ser sin estado, permitiendo un escalado horizontal fácil. * **Servicio de Generación de ID:** Debe ser de alta disponibilidad y escalable para manejar la tasa de creación de nuevos enlaces. * **Tráfico de Analíticas:** * **Procesamiento Asíncrono:** Usar una cola de mensajes (Kafka, Kinesis) para almacenar temporalmente los eventos de clics. Esto desacopla la ruta de redirección del procesamiento de analíticas. * **Pipeline de Analíticas Escalable:** El Servicio de Analíticas puede escalar horizontalmente para procesar mensajes de la cola y actualizar la Base de Datos de Analíticas. * **Almacén de Datos:** Para analíticas a gran escala, un almacén de datos es más adecuado que un RDBMS tradicional. ### 5. Fiabilidad y Recuperación ante Desastres * **Despliegue Multi-AZ:** Todos los servicios y bases de datos se desplegarán en múltiples Zonas de Disponibilidad dentro de una región. * **Despliegue Multi-Región:** Para servicios críticos (Resolución de Enlaces, API Gateway), desplegar en múltiples regiones geográficas. Usar GeoDNS para failover. * **Replicación de Datos:** Las bases de datos tendrán replicación habilitada (por ejemplo, multi-maestro o primario-réplica con failover automático). * **Idempotencia:** Asegurar que las operaciones críticas (como la creación de enlaces) sean idempotentes para manejar reintentos de forma segura. * **Degradación Elegante:** Si el Servicio de Analíticas está caído, las redirecciones deberían seguir funcionando. Si la Base de Datos de Metadatos es lenta, el rendimiento de la caché podría degradarse, pero las redirecciones deberían seguir funcionando si están en caché. * **Copias de Seguridad:** Copias de seguridad automáticas regulares de todos los datos persistentes. ### 6. Compromisos Clave * **Generación de ID:** * **Centralizada (por ejemplo, Snowflake):** Garantiza la unicidad, buen rendimiento, pero introduce una dependencia del servicio de ID. Puede ser un punto único de falla si no es de alta disponibilidad. * **Autoincremento de Base de Datos:** Simple, pero puede ser un cuello de botella y más difícil de escalar entre fragmentos/regiones. * **Hash Aleatorio:** Más simple de generar, pero requiere detección de colisiones y podría resultar en ID más largos si no se diseña cuidadosamente. * **Elegido:** Servicio de generación de ID distribuido (similar a Snowflake) para un equilibrio de unicidad, rendimiento y disponibilidad. * **Selección de Base de Datos:** * **NoSQL (Cassandra):** Excelente para alto rendimiento de escritura y escalabilidad horizontal, bueno para la disponibilidad. Flexibilidad de esquema. Puede ser complejo de administrar. * **Relacional (PostgreSQL Fragmentado):** Fuerte consistencia, interfaz SQL familiar. La fragmentación añade complejidad. * **Elegido:** Cassandra para Metadatos (alta escritura/lectura, disponibilidad) y una Base de Datos de Series Temporales/Almacén de Datos para Analíticas (rendimiento de consulta). * **Caché:** * **Estrategia de Invalidez de Caché:** Cache-aside con TTL es común. Para actualizaciones (dentro de los 10 minutos), se necesita invalidación explícita. Para expiración, el TTL lo maneja. * **Consistencia vs. Disponibilidad:** El almacenamiento en caché agresivo mejora la disponibilidad y la latencia, pero puede generar datos obsoletos si no se invalidan correctamente. * **Elegido:** Cache-aside con TTL cortos para mapeos de `short_id` a `long_url`. Invalidar en actualizaciones. * **Consistencia:** * **Consistencia Eventual:** Aceptable para analíticas. Para la resolución de enlaces, se prefiere la consistencia fuerte, pero puede relajarse con el almacenamiento en caché. * **Creación de Enlaces:** Fuerte consistencia para la unicidad de `short_id`. Los alias personalizados pueden tener un ligero retraso en la propagación entre réplicas. * **Elegido:** Consistencia eventual para analíticas. Fuerte consistencia para la generación de ID y la unicidad de la creación de enlaces. Consistencia relajada para la resolución de enlaces a través de caché. * **Pipeline de Analíticas:** * **Tiempo Real vs. Casi Tiempo Real:** El requisito es de ~5 minutos. Esto es factible con procesamiento de streams (por ejemplo, Kafka Streams, Flink) o micro-lotes. * **Complejidad:** Un pipeline completo en tiempo real es complejo. Un enfoque de procesamiento por lotes (por ejemplo, agregación diaria) es más simple pero no cumple el requisito de 5 minutos. * **Elegido:** Kafka + procesamiento de streams (por ejemplo, Flink o Spark Streaming) para agregación casi en tiempo real en la Base de Datos de Analíticas. ### 7. Monitoreo y Detección de Fallos * **Métricas Clave:** * **Latencia:** Latencia P95/P99 para API Gateway, Creación de Enlaces, Resolución de Enlaces y APIs de Analíticas. * **Tasas de Error:** Tasas de error HTTP 5xx y 4xx para todos los servicios. * **Rendimiento:** Solicitudes por segundo para creación y resolución de enlaces. * **Utilización de Recursos:** CPU, memoria, E/S de red, E/S de disco para todos los servicios y bases de datos. * **Tasa de Éxito de Caché:** Para la caché de lectura. * **Profundidad de Cola:** Para la cola de mensajes. * **Rendimiento de Base de Datos:** Latencia de consulta, recuento de conexiones, retraso de replicación. * **Herramientas:** * **Recolección de Métricas:** Prometheus, Datadog, CloudWatch. * **Registro:** Sistema de registro centralizado (por ejemplo, stack ELK, Splunk, CloudWatch Logs). * **Trazado:** Trazado distribuido (por ejemplo, Jaeger, Zipkin) para seguir solicitudes entre servicios. * **Alertas:** Alertmanager, PagerDuty para problemas críticos. * **Detección de Fallos:** * **Comprobaciones de Salud:** Implementar comprobaciones de salud profundas para todos los servicios y dependencias. * **Monitoreo Sintético:** Hacer ping regularmente a los endpoints críticos (por ejemplo, crear enlace, resolver un enlace conocido) desde ubicaciones externas. * **Detección de Anomalías:** Monitorear métricas para picos o caídas repentinas que se desvíen de los patrones normales. * **Rollbacks Automatizados:** Configurar pipelines de CI/CD para revertir automáticamente los despliegues si se activan alertas críticas. * **Ingeniería del Caos:** Inyectar periódicamente fallos (por ejemplo, latencia de red, interrupciones de servicio) en un entorno controlado para probar la resiliencia.

Arquitectura de Alto Nivel y Componentes Principales El sistema se organiza en varias capas desplegadas en al menos dos regiones geográficas (US-East y EU-West) detrás de un DNS anycast global o un balanceador de carga global como AWS Global Accelerator o Cloudflare. 1. Capa de Edge y CDN: Un balanceador de carga global dirige a los usuarios al clúster regional más cercano. Una CDN o caché de borde (Cloudflare Workers, CloudFront) almacena en caché los mapeos de redirección populares en el borde para lograr una latencia P95 inferior a 80 ms. 2. API Gateway y Limitador de Tasa: Cada región ejecuta una API gateway que maneja la autenticación, la limitación de tasa y el enrutamiento de solicitudes. La limitación de tasa utiliza un contador de ventana deslizante respaldado por Redis para limitar los patrones de creación abusivos. 3. Servicio de Creación de Enlaces: Servicio sin estado detrás de la API gateway. Acepta URLs largas, alias personalizados opcionales, caducidad opcional y devuelve un código corto. Escribe en la base de datos principal e invalida o calienta la caché. 4. Servicio de Redirección: La ruta más transitada. Recibe solicitudes GET en códigos cortos, busca la URL de destino (primero en caché, luego en la base de datos), emite una redirección HTTP 301 o 302 y emite un evento de clic al pipeline de análisis. Utiliza redirecciones 302 para que el servicio siempre vea la solicitud para el análisis, pero devuelve una cabecera Cache-Control con un TTL corto (por ejemplo, 60 s) para que los navegadores y los bordes de la CDN puedan almacenar en caché. 5. Pipeline de Análisis: Los eventos de clic se publican en un stream distribuido (Kafka o AWS Kinesis). Un procesador de stream (Flink o Kafka Streams) agrega clics por enlace en ventanas de un minuto y escribe los resúmenes en un almacén de análisis. Una API simple sirve análisis agregados. 6. Servicio de Prevención de Abusos: En la creación de enlaces, la URL de destino se verifica contra la API de Google Safe Browsing y una lista interna de bloqueo. Un clasificador ligero de ML marca patrones sospechosos (creación masiva, dominios de spam conocidos). Los enlaces marcados se retienen para su revisión o se rechazan. 7. Trabajador de Caducidad y Limpieza: Un trabajo periódico (cron o Lambda programada) escanea los enlaces caducados y los elimina lógicamente, eliminándolos de la caché. Modelo de Datos Central y Opciones de Almacenamiento Almacén Principal de Enlaces: Una base de datos NoSQL distribuida como Amazon DynamoDB o Apache Cassandra. La tabla se indexa por short_code (clave de partición). Campos del esquema: short_code (cadena, clave primaria), long_url (cadena), user_id (cadena), created_at (timestamp), expires_at (timestamp, nulo), custom_alias (booleano), updated_at (timestamp). Se elige DynamoDB por sus lecturas de un solo dígito de milisegundos, replicación multirregional automática a través de Tablas Globales y escalado administrado. Cassandra es una alternativa para equipos que desean evitar el bloqueo del proveedor. Capa de Caché: Redis Cluster (o ElastiCache) en cada región. Entrada de caché: short_code -> long_url con un TTL que coincide con la caducidad del enlace o un valor predeterminado de 24 horas. Patrón cache-aside: el servicio de redirección verifica Redis primero; en caso de fallo, lee de DynamoDB y rellena Redis. Almacén de Análisis: Un almacén de series temporales o columnar. ClickHouse o Amazon Timestream almacenan agregados de clics por enlace con dimensiones: short_code, timestamp_bucket, country, referrer, device_type. Resúmenes preagregados con granularidad de 1 minuto, 1 hora y 1 día. Almacén de Usuarios y Cuentas: Una base de datos relacional (PostgreSQL a través de RDS) almacena cuentas de usuario, claves API, facturación y metadatos de propiedad de enlaces. Esto tiene menos tráfico y se beneficia de la consistencia fuerte y las consultas relacionales. Diseño de API Crear Enlace Corto: POST /api/v1/links. Cuerpo de la solicitud: long_url (requerido), custom_alias (opcional), expires_at (opcional). Respuesta: 201 Created con short_code, short_url, created_at, expires_at. Errores: 409 Conflict si el alias personalizado está ocupado, 400 si la URL no es válida, 403 si se detecta abuso. Actualizar URL de Destino: PATCH /api/v1/links/{short_code}. Cuerpo de la solicitud: long_url. Permitido solo dentro de los 10 minutos posteriores a created_at. Respuesta: 200 OK con el registro actualizado. Error: 403 si está fuera de la ventana de 10 minutos o no es el propietario. Resolver (Redireccionar): GET /{short_code}. Respuesta: 302 Found con la cabecera Location establecida en long_url. Si caducó o no se encontró: 404. El servicio de redirección también establece cabeceras de respuesta para el control de caché. Leer Análisis: GET /api/v1/links/{short_code}/analytics?start=...&end=...&granularity=hour. Respuesta: 200 OK con una matriz de recuentos de clics por intervalo de tiempo, países principales, referidores principales. Eliminar Enlace: DELETE /api/v1/links/{short_code}. Elimina lógicamente el enlace e invalida la caché. Estrategia de Generación de ID Los códigos cortos son de 7 caracteres de un alfabeto base-62 (a-z, A-Z, 0-9), lo que da aproximadamente 3.5 billones de códigos posibles, superando con creces el volumen de enlaces esperado durante muchos años. Enfoque de generación: A cada instancia de servicio se le asigna un ID de trabajador único (de un servicio de coordinación o configuración). Un generador de ID similar a Snowflake produce un entero único de 64 bits que combina un componente de marca de tiempo, un ID de trabajador y un número de secuencia. Luego, el entero se codifica en base-62 y se trunca o rellena a 7 caracteres. Esto evita la coordinación en cada escritura y garantiza la unicidad. Para alias personalizados, el servicio intenta una inserción con una restricción de unicidad; en caso de conflicto, devuelve 409. Estrategia de Escalado para Crecimiento de Tráfico y Manejo de Ráfagas Cálculo en estado estacionario: 1.5 mil millones de redirecciones por mes son aproximadamente 580 solicitudes por segundo en promedio, con picos durante eventos de noticias que potencialmente alcanzan 10-50 veces, por lo que la ruta de redirección debe manejar al menos 30,000 RPS por región. La creación de enlaces a 120 millones por mes es de aproximadamente 46 RPS en promedio. Escalado de la ruta de redirección: El servicio de redirección no tiene estado y es escalable horizontalmente detrás de un grupo de autoescalado. Redis maneja la gran mayoría de las lecturas; la capacidad bajo demanda de DynamoDB maneja las fallas de caché. La caché de borde de la CDN absorbe una gran fracción de las solicitudes repetidas para enlaces virales, reduciendo la carga del origen. Manejo de ráfagas: Políticas de autoescalado basadas en CPU y recuento de solicitudes con escalado agresivo (agregar 50 por ciento de capacidad en 60 segundos). El clúster de Redis se puede preescalar con réplicas de lectura. El modo bajo demanda de DynamoDB absorbe ráfagas de escrituras y lecturas sin preaprovisionamiento. La CDN absorbe de forma natural el tráfico de lectura de ráfagas para enlaces populares. Escalado de la ruta de creación: Menos ráfagas pero aún con autoescalado. Las escrituras van a la Tabla Global de DynamoDB regional, que se replica asincrónicamente a otras regiones. Escalado del pipeline de análisis: Las particiones de Kafka se indexan por short_code para paralelismo. El grupo de consumidores de Flink escala horizontalmente. El clúster de ClickHouse puede agregar shards para el rendimiento de las consultas. Fiabilidad y Recuperación ante Desastres Activo-activo multirregional: Las Tablas Globales de DynamoDB replican datos entre US-East y EU-West con resolución de conflictos de último escritor gana. Ambas regiones atienden lecturas y escrituras. Si una región falla, las comprobaciones de estado DNS (Route 53 o equivalente) dirigen todo el tráfico a la región superviviente en segundos. Replicación de Redis: Cada región tiene su propio clúster de Redis poblado desde la réplica local de DynamoDB. Si Redis falla, el servicio de redirección recurre a lecturas de DynamoDB con latencia ligeramente mayor. Durabilidad de Kafka: Los temas de Kafka tienen un factor de replicación de 3 con min.insync.replicas=2. Si el pipeline de análisis se retrasa, los eventos de clic se conservan en Kafka durante al menos 72 horas para su reproducción. Copias de seguridad: Se habilita la recuperación puntual de DynamoDB. PostgreSQL tiene instantáneas diarias automatizadas con replicación entre regiones. Los datos de ClickHouse se copian en S3 diariamente. Degradación elegante: Si el servicio de verificación de abusos es lento, las solicitudes de creación continúan con una marca para revisión asincrónica en lugar de bloquearse. Si el pipeline de análisis está caído, las redirecciones continúan sin verse afectadas; los eventos de clic se ponen en cola en Kafka. Compromisos Clave Generación de ID: Los ID estilo Snowflake evitan un cuello de botella de contador centralizado pero requieren coordinación de ID de trabajador. La codificación Base-62 de ID de 64 bits produce códigos cortos y seguros para URL. Compromiso: códigos ligeramente más largos (7 caracteres) de lo estrictamente necesario para evitar colisiones y permitir el crecimiento futuro. Selección de base de datos: Se elige DynamoDB por su escalado administrado, lecturas de baja latencia y replicación global incorporada. Compromiso: consistencia eventual entre regiones (aceptable ya que la creación de enlaces no es crítica para la latencia entre regiones, y las redirecciones dentro de la misma región son consistentes). Cassandra ofrecería propiedades similares con mayor carga operativa pero sin bloqueo del proveedor. Caché: El patrón cache-aside con Redis proporciona lecturas de sub-milisegundos para enlaces populares. Compromiso: la invalidación de caché en actualizaciones de URL dentro de la ventana de 10 minutos requiere invalidación explícita entre regiones, introduciendo una breve ventana de datos obsoletos (mitigada por TTLs de caché cortos para enlaces creados recientemente, por ejemplo, 30 segundos para enlaces de menos de 10 minutos de antigüedad). Consistencia: El sistema favorece la disponibilidad y la tolerancia a particiones (AP en términos CAP). Las lecturas de redirección son eventualmente consistentes, lo cual es aceptable. La ventana de actualización de 10 minutos se aplica en la capa de aplicación; en escenarios raros de partición del sistema, podría ocurrir una redirección obsoleta brevemente. Pipeline de análisis: Kafka más Flink más ClickHouse proporciona análisis casi en tiempo real dentro del SLA de 5 minutos. Compromiso: esto agrega complejidad operativa. Una alternativa más simple sería escribir registros de clics en S3 y consultarlos con Athena, pero eso no cumpliría el requisito de frescura de 5 minutos. Redirecciones 302 vs 301: Se utiliza 302 (temporal) para que el servicio vea cada clic para el análisis. Compromiso: latencia ligeramente mayor para visitantes recurrentes en comparación con 301, pero la caché de borde de la CDN con un TTL de 60 segundos lo mitiga y aún captura la mayoría de los clics. Monitorización y Detección de Fallos Métricas: Cada servicio emite métricas a un sistema de monitorización de series temporales (Prometheus más Grafana, o CloudWatch). Las métricas clave incluyen latencia P50, P95 y P99 de redirección; ratio de aciertos de caché (objetivo superior al 95 por ciento); capacidad consumida de lectura y escritura de DynamoDB; latencia del consumidor de Kafka; tasas de error por endpoint; tasa de creación de enlaces. Alertas: Alertas de PagerDuty si la latencia P95 de redirección supera los 80 ms, el ratio de aciertos de caché cae por debajo del 90 por ciento, la latencia del consumidor de Kafka supera los 5 minutos (SLA de análisis), la tasa de error es superior al 1 por ciento en cualquier endpoint y falla la comprobación de estado de cualquier región. Seguimiento distribuido: Trazas de OpenTelemetry a través de la ruta de redirección (borde a caché a base de datos a respuesta) para diagnosticar regresiones de latencia. Monitorización sintética: Solicitudes Canary desde múltiples ubicaciones geográficas crean y resuelven continuamente enlaces cortos, alertando si la latencia o la corrección de extremo a extremo se degradan. Agregación de logs: Logs estructurados enviados a un sistema centralizado (ELK o CloudWatch Logs) para depuración y pistas de auditoría. Comprobaciones de estado: Cada servicio expone un endpoint de estado. El balanceador de carga elimina las instancias no saludables. Las comprobaciones de estado entre regiones activan el failover DNS. Supuestos Adicionales: Los usuarios se autentican mediante claves API para la creación de enlaces y el análisis. La creación de enlaces anónimos está limitada por IP. El sistema se ejecuta en AWS, pero el diseño es portable. Los códigos cortos distinguen entre mayúsculas y minúsculas. El servicio no necesita soportar miles de millones de enlaces activos concurrentes a corto plazo, pero el espacio de códigos de 7 caracteres permite un crecimiento hasta billones.