Diseñar un acortador de URL para 10K solicitudes por segundo

Diseño de sistemas: acortador de URL escalable

Supuestos

1. El tráfico de redirección alcanza picos de 10.000 solicitudes por segundo. Una relación nominal de 100:1 entre lecturas y escrituras implica aproximadamente 100 creaciones por segundo en ese pico.

2. Treinta mil millones de enlaces en cinco años requieren aproximadamente 190 creaciones por segundo en promedio, por lo que la ruta de almacenamiento y escritura se aprovisionará para al menos 1.000 creaciones por segundo para conciliar esta cifra y absorber ráfagas.

3. Los enlaces son inmutables por defecto. Si posteriormente se admite la eliminación o la edición del destino, se utiliza versionado explícito e invalidación de caché.

4. Las analíticas básicas pueden ser eventualmente consistentes y pueden perder un número muy pequeño de eventos durante fallos catastróficos. La corrección de la redirección no depende de las analíticas.

5. Las respuestas de redirección utilizan HTTP 302 o 307 en lugar de redirecciones 301 permanentes, lo que preserva el control operativo y mejora la visibilidad de las analíticas.

6. El servicio se ejecuta activo-activo en al menos tres regiones geográficas y utiliza una base de datos de enlaces replicada globalmente.

7. Arquitectura de alto nivel

Los componentes son DNS global o enrutamiento Anycast, balanceadores de carga regionales, servicios de redirección sin estado, servicios de creación sin estado, cachés locales en memoria, cachés distribuidos regionales, una base de datos de enlaces particionada, un flujo de eventos duradero, y procesadores y almacenamiento de analíticas.

Ruta de creación

1. Un cliente envía la URL larga y un alias personalizado opcional a la región sana más cercana.
2. La API autentica o limita la velocidad del llamador, valida la sintaxis de la URL, limita la longitud de la URL, permite solo esquemas compatibles como HTTP y HTTPS, y verifica alias reservados.
3. Para un enlace generado automáticamente, el servicio crea un código criptográficamente aleatorio. Para un alias personalizado, normaliza el alias según una política documentada, sensible o insensible a mayúsculas y minúsculas.
4. El servicio de creación realiza una inserción condicional en la base de datos autoritativa: inserta solo si el código o alias no existen ya.
5. En caso de colisión aleatoria, genera otro código y reintenta. En caso de colisión de alias personalizado, devuelve HTTP 409 sin cambiar silenciosamente el alias solicitado.
6. Después de que la base de datos confirma la escritura, el servicio inserta la nueva asignación en la caché regional local y difunde un mensaje de llenado o invalidación de caché a otras regiones.
7. Devuelve la URL corta. Una clave de idempotencia de solicitud puede mapear solicitudes repetidas del cliente al mismo resultado.

La escritura se confirma solo después de un quórum o consenso de confirmación. Esto añade latencia de escritura entre zonas y, dependiendo de la configuración de la base de datos, entre regiones, pero crea una garantía de unicidad global autoritativa. La creación es mucho menos sensible a la latencia que el tráfico de redirección.

Ruta de redirección

1. El enrutamiento global envía la solicitud a la región sana más cercana.
2. El servicio de redirección valida y extrae el código.
3. Comprueba una pequeña caché en memoria. Si está ausente, comprueba la caché distribuida regional.
4. En caso de fallo de caché, realiza una búsqueda puntual en una réplica local de la base de datos utilizando el código como clave principal.
5. Si se encuentra y está activo, rellena ambos niveles de caché, emite asincrónicamente un evento de clic y devuelve inmediatamente una respuesta 302 o 307 que contiene el destino.
6. Si está ausente, devuelve 404. Los resultados negativos se almacenan en caché solo brevemente.

La ruta de redirección no tiene operación de analíticas síncrona ni salto de red entre regiones en condiciones normales. Los servicios sin estado escalan horizontalmente detrás de balanceadores de carga regionales.

2. Generación y unicidad de códigos cortos

Un espacio base62 de siete caracteres contiene 62^7, aproximadamente 3,52 billones, de valores y técnicamente puede albergar 30 mil millones de enlaces. Sin embargo, con 30 mil millones de enlaces almacenados, aproximadamente el 0,85 por ciento de ese espacio de nombres está ocupado. Un escáner masivo aleatorio descubriría, por lo tanto, aproximadamente un enlace válido por cada 117 intentos, lo que no satisface el requisito de que los códigos sean difíciles de adivinar en masa.

Por lo tanto, el código por defecto utilizará 11 caracteres base62 seguros para URL generados a partir de una fuente aleatoria criptográficamente segura. Esto proporciona aproximadamente 65,5 bits y 5,2 × 10^19 posibilidades. Con 30 mil millones de enlaces activos, una suposición aleatoria tiene una probabilidad de éxito de alrededor de 5,8 × 10^-10. La limitación de velocidad y la detección de abusos restringen aún más la enumeración. La contrapartida es un enlace cuatro caracteres más largo. Los alias de siete caracteres aún pueden permitirse cuando los eligen explícitamente los usuarios, pero no reciben la misma garantía de no enumerabilidad.

La generación aleatoria evita exponer el orden de creación y distribuye las claves de manera uniforme. Una inserción condicional de clave principal es la autoridad de unicidad final. Se esperan colisiones de cumpleaños en el historial completo en un sistema aleatorio, pero solo las colisiones de candidatos simultáneas importan operativamente: cada inserción intentada se verifica y se reintenta. Con la ocupación planificada del espacio de 11 caracteres, los reintentos son efectivamente inexistentes.

Una alternativa sería cifrar o aplicar una permutación con clave a un número de secuencia. Eso garantiza entradas generadas únicas pero requiere gestión del ciclo de vida de la clave y asignación de secuencias. La generación aleatoria más la inserción condicional es más simple, elimina la asignación de ID centralizada y es suficientemente eficiente a este tamaño de espacio de nombres.

Los alias personalizados comparten el mismo espacio de nombres de clave principal que los códigos generados. La normalización del alias se produce antes de la inserción, y una inserción condicional globalmente consistente decide el ganador de las solicitudes concurrentes. Se rechazan rutas reservadas como salud, API, admin y estáticas. Si los alias no distinguen entre mayúsculas y minúsculas, la forma normalizada en minúsculas es la clave, mientras que la forma de visualización solicitada puede almacenarse por separado.

3. Modelo de datos y base de datos

Los campos del registro de enlace autoritativo son:

código: clave principal
long_url: URL de destino
created_at: marca de tiempo
owner_id: identificador de cuenta opcional
status: activo, deshabilitado o eliminado
ttl_or_expiry: opcional
version: valor que aumenta monótonamente para la invalidación de caché
custom_alias: booleano

Los recuentos de clics no se actualizan en este registro en cada redirección porque eso convertiría los enlaces populares en puntos críticos de escritura.

El almacén de enlaces es una base de datos distribuida y particionada de clave-valor optimizada para acceso por clave principal, como DynamoDB, Bigtable, Cassandra con consistencia cuidadosamente gestionada, o un sistema equivalente operado internamente. Para escrituras condicionales globalmente únicas, la implementación seleccionada debe proporcionar creación condicional linealizable para una clave, ya sea de forma nativa o a través de líderes de consenso por fragmento. Las uniones relacionales y los escaneos de rango no son necesarios en la ruta de redirección.

La clave de partición principal es un hash del código completo. La distribución de hash evita puntos críticos cronológicos y distribuye uniformemente tanto los códigos generados como los alias personalizados. El espacio de claves lógico se divide en miles de fragmentos virtuales, que se reasignan a medida que se agregan nodos. Cada fragmento tiene al menos tres réplicas en diferentes zonas de disponibilidad, con réplicas adicionales entre regiones.

Estimación de capacidad

Suponga una URL promedio de 400 bytes y aproximadamente 200 bytes para claves, metadatos, codificación, índices y sobrecarga del motor de almacenamiento. Con aproximadamente 600 bytes por registro, 30 mil millones de registros requieren alrededor de 18 TB de datos lógicos. Permitiendo URL más largas, sobrecarga de compactación, marcadores de tumba y margen operativo, presupueste 30 TB lógicos. Tres réplicas duraderas requieren aproximadamente 90 TB, y las copias de seguridad más las copias entre regiones pueden elevar la asignación de la flota a aproximadamente 150-250 TB. Esto está bien dentro del rango previsto de almacenes de clave-valor particionados horizontalmente, pero no es adecuado para una sola instancia de base de datos convencional.

A 10.000 redirecciones por segundo, incluso una interrupción completa de la caché genera solo 10.000 lecturas puntuales aleatorias por segundo. La base de datos se aprovisiona para al menos 20.000-30.000 lecturas por segundo por región de servicio durante la conmutación por error y al menos 1.000 creaciones condicionales por segundo. La capacidad se rige más por el tamaño del conjunto de datos, la replicación y la reserva de conmutación por error que por el rendimiento normal de las solicitudes.

Las analíticas utilizan almacenamiento separado. Un procesador de flujo escribe recuentos por código y por intervalo de tiempo en un almacén de clave-valor o columnar de analíticas con un modelo como código más día u hora como clave y recuento como valor. Un total compacto se puede mantener de forma asíncrona. Mantener las analíticas separadas evita que los contadores de enlaces virales compitan con las búsquedas de redirección.

4. Estrategia de caché

Cada proceso de redirección tiene una caché en memoria LRU o TinyLFU acotada para las asignaciones más populares. Un clúster regional compatible con Redis o Memcached forma el segundo nivel. Los valores almacenados en caché incluyen el destino, el estado, la caducidad y la versión del registro.

Un objetivo representativo es una tasa de aciertos de caché regional del 95-99 por ciento. La popularidad de URL similar a Zipf generalmente hace que esto sea factible a pesar de que el corpus total es muy grande. La caché almacena objetos populares, no los 30 mil millones de enlaces. Por ejemplo, 100 millones de entradas a aproximadamente 600 bytes cada una consumen unos 60 GB antes de la sobrecarga de caché y quizás 100-150 GB en la práctica, distribuidos en un clúster de caché regional.

Las asignaciones son inmutables por defecto, por lo que las entradas positivas pueden tener un TTL largo, como 6-24 horas con fluctuación. Si se admite la edición, deshabilitación o eliminación, la escritura autoritativa se confirma primero y luego publica una invalidación que contiene el código y la nueva versión a todas las regiones. TTL más cortos limitan el tiempo de servicio obsoleto si se pierde una invalidación. Las operaciones de deshabilitación sensibles a la seguridad también pueden colocar una pequeña lista de bloqueo global en cada proceso de redirección.

Los resultados negativos se almacenan en caché durante aproximadamente 5-30 segundos para resistir escaneos repetidos. La ruta de creación invalida las entradas de caché negativas después de reclamar con éxito un código. El TTL negativo corto limita una condición de carrera en la que otra región almacenó brevemente un fallo antes de que llegara la replicación o la invalidación.

En caso de fallo de caché, el servicio de redirección lee la réplica de la base de datos regional y rellena ambos niveles de caché. La coalescencia de solicitudes garantiza que los fallos concurrentes para un código recién popular generen una solicitud de base de datos en lugar de miles. La fluctuación del TTL evita la expiración sincronizada. La base de datos se dimensiona para soportar la carga completa de 10.000 solicitudes por segundo si la caché distribuida falla, aceptando una latencia algo mayor mientras permanece funcional.

La contrapartida de los TTL de caché largos es la posible obsolescencia después de las ediciones. La inmutabilidad, las invalidaciones versionadas y los TTL acotados hacen explícita esa contrapartida. La corrección de la redirección para enlaces recién creados se puede mejorar rellenando de forma síncrona la región de creación y dirigiendo una lectura inmediata a esa región cuando sea necesario.

5. Escalado y latencia

Los servicios de redirección no tienen estado y escalan horizontalmente en función de las solicitudes por segundo, la CPU y la latencia p99. Si una instancia procesa de forma segura 1.000 solicitudes por segundo, cada región podría ejecutar al menos 15-20 instancias para una carga de conmutación por error regional de 10.000 solicitudes por segundo, además de la sobrecarga de despliegue y fallo de zona. El dimensionamiento real se establece mediante pruebas de carga.

Un presupuesto de latencia normal con acierto de caché es de aproximadamente 2-5 ms para balanceo de carga y trabajo de aplicación, 1-3 ms para una búsqueda en memoria o 2-8 ms para una búsqueda en caché distribuida regional, y unos pocos milisegundos para construir la respuesta. Un presupuesto de fallo de caché asigna aproximadamente 10-25 ms a una búsqueda puntual en una base de datos replicada local.

Los tiempos de espera estrictos por salto evitan que una caché o réplica dañada consuma todo el presupuesto de latencia. El acceso a la caché puede limitarse a aproximadamente 8 ms y el acceso a la base de datos a aproximadamente 25-30 ms, con reintentos solo cuando queda suficiente presupuesto. Las lecturas con cobertura a una segunda réplica local pueden usarse para el percentil más lento, pero se retrasan y limitan la velocidad para evitar duplicar la carga normal.

Las claves se particionan por hash en fragmentos virtuales. Los códigos generados aleatoriamente equilibran el tráfico de forma natural, mientras que un enlace individual excepcionalmente popular es absorbido por las cachés en memoria y regionales. Si una clave popular llega a la base de datos, la coalescencia de solicitudes y las lecturas replicadas evitan que un nodo de almacenamiento se convierta en el cuello de botella.

El escalado automático mantiene suficiente capacidad para una pérdida completa de zona de disponibilidad y al menos una región que reciba tráfico redirigido de un par fallido. Las regiones operan por debajo de aproximadamente el 50-60 por ciento de la capacidad máxima. La contrapartida es un mayor costo inactivo a cambio del objetivo de disponibilidad del 99,99 por ciento.

6. Fiabilidad y manejo de fallos

Objetivo de disponibilidad

Un objetivo mensual del 99,99 por ciento permite aproximadamente 4,4 minutos de indisponibilidad en un mes de 30 días. No se puede requerir ningún nodo de caché, instancia de aplicación, zona de disponibilidad o región para las redirecciones.

Fallo de instancia de aplicación o zona

Las comprobaciones de estado eliminan las instancias fallidas y los balanceadores de carga distribuyen las solicitudes entre al menos tres zonas. Los servicios utilizan despliegues continuos o canary, drenaje de conexiones y reversión automatizada. La capacidad regional sobrevive a la pérdida de una zona.

Fallo de nodo o clúster de caché

Los nodos de caché se fragmentan y replican dentro de una región. Si falla un nodo individual, su réplica toma el control. Si toda la caché no está disponible, los servicios de redirección utilizan disyuntores, omiten las llamadas a la caché y consultan directamente la base de datos. La capacidad de la base de datos y los pools de conexiones de aplicaciones se aprovisionan explícitamente para este modo. El control de admisión protege la base de datos del tráfico de escaneo ilimitado.

Fallo de nodo de base de datos

Cada fragmento se replica en diferentes zonas utilizando quórum o consenso. Un líder fallido se reemplaza automáticamente; las lecturas utilizan otra réplica local sana. Las creaciones condicionales permanecen no disponibles para un fragmento durante la breve elección en lugar de arriesgarse a una propiedad duplicada. Las redirecciones pueden continuar desde réplicas y cachés. Esto favorece la corrección para la creación mientras se preserva la disponibilidad de lectura.

Fallo de región

El enrutamiento global basado en el estado elimina la región fallida y envía el tráfico a la región sana más cercana. Cada región de servicio tiene una copia replicada de los datos del enlace e infraestructura independiente de redirección, caché e ingesta de eventos. La tasa de aciertos de caché será inicialmente menor después de la conmutación por error, por lo que las regiones en espera retienen cachés calientes para enlaces globalmente populares y suficiente capacidad de base de datos/lectura para el aumento de caché fría.

Para los códigos generados, la replicación global puede ser asíncrona después de una inserción autoritativa respaldada por consenso si la arquitectura de la base de datos dirige cada clave a un fragmento de origen. Para alias personalizados, la inserción condicional autoritativa debe permanecer serializada globalmente. Si un enlace recién creado no ha llegado a una región superviviente antes de una pérdida catastrófica, el servicio puede devolver brevemente un error reintentable en lugar de una asignación incorrecta. Una replicación multirregional síncrona más sólida reduce esta ventana de punto de recuperación pero aumenta la latencia de creación. La configuración preferida confirma la creación de enlaces en réplicas en al menos dos regiones porque las escrituras son de volumen relativamente bajo.

Copias de seguridad y corrupción

La base de datos utiliza sumas de verificación, recuperación puntual, instantáneas inmutables y procedimientos de restauración probados regularmente. Las eliminaciones utilizan marcadores de tumba y un período de retención en lugar de la eliminación física inmediata. Las copias de seguridad protegen contra la corrupción lógica pero no forman parte de la conmutación por error de redirección normal.

Comportamiento de sobrecarga

Se aplican límites de velocidad por origen, cuenta y patrón de escaneo de código sospechoso. El tráfico de creación y analíticas tiene menor prioridad que las redirecciones. La descarga de carga rechaza las solicitudes de creación abusivas o excesivas antes de que afecten la capacidad de redirección. Los disyuntores, las colas acotadas y los plazos de entrega evitan fallos en cascada.

7. Analíticas de clics

Después de seleccionar el destino de redirección, el servicio crea un evento compacto que contiene un ID de evento, código, marca de tiempo, región y, opcionalmente, campos de referente o agente de usuario aproximados. Coloca el evento en un búfer asíncrono local acotado y devuelve la redirección sin esperar la confirmación de las analíticas.

Un colector regional agrupa los eventos en un flujo replicado duradero como Kafka, Pulsar o Kinesis. Los procesadores de flujo agregan eventos por código y por intervalo de tiempo, y luego escriben incrementos por lotes en el almacén de analíticas. La compactación periódica produce recuentos totales de clics. Los paneles y las API leen el almacén de analíticas, nunca la tabla de redirección autoritativa.

Los ID de evento permiten la deduplicación posterior cuando los colectores reintentan. La partición del flujo directamente por código concentraría un enlace viral en una partición, por lo que la clave de ingesta puede ser código más una raya aleatoria. Los procesadores primero agregan los contadores rayados y luego los fusionan. Esto permite que las analíticas de enlaces populares escalen horizontalmente.

Un búfer asíncrono puramente en memoria puede perder eventos si un proceso de redirección falla. Si se requiere una mayor durabilidad, cada host o sidecar puede añadir lotes a un registro de escritura anticipada local antes de reenviarlos, pero las respuestas de redirección aún no deben esperar al flujo central. La contrapartida aceptada para las analíticas básicas es la consistencia eventual y un pequeño recuento insuficiente medido durante fallos graves a cambio de preservar la latencia y la disponibilidad de la redirección.

Resultado

La ruta de redirección normal es una búsqueda en caché local seguida, solo en caso de fallo, por una búsqueda local en una base de datos de clave-valor particionada. Los códigos aleatorios de 11 caracteres evitan la exposición secuencial y hacen que las suposiciones masivas exitosas sean poco prácticas. Las inserciones condicionales proporcionan unicidad, el particionamiento por hash soporta el corpus de 30 mil millones de registros, el servicio regional activo-activo elimina los puntos únicos de fallo regionales, y las analíticas rayadas asíncronas mantienen las escrituras de contadores completamente fuera de la ruta crítica de latencia.

Diseño del Sistema: Acortador de URL (10K RPS)

Supuestos:

• Estamos diseñando inicialmente para una sola región, con multi-región como una mejora futura.
• El enfoque principal está en la ruta de redirección debido a la relación de lectura:escritura de 100:1.
• Los alias personalizados son una característica secundaria y pueden tolerar latencia ligeramente mayor o indisponibilidad ocasional en comparación con las redirecciones estándar.
• Las analíticas de clics no son estrictamente en tiempo real y pueden tener un ligero retraso.

1. Arquitectura de Alto Nivel y Flujo de Solicitudes

Ruta de Escritura (Crear Enlace Corto):

1. API Gateway: Recibe la solicitud POST con la URL larga y el alias personalizado opcional.
2. Balanceador de Carga: Distribuye las solicitudes de escritura a las instancias de la API del Servicio Acortador de URL (US).
3. API US (Servicio de Escritura):
   • Valida la URL de entrada.
   • Genera un código corto (ver Sección 2).
   • Si se proporciona un alias personalizado, intenta reservarlo primero (ver Sección 2).
   • Persiste el mapeo (código_corto -> url_original, alias_personalizado -> código_corto) en el almacén de datos.
   • Devuelve la URL corta generada al cliente.

Ruta de Lectura (Redirección):

1. API Gateway: Recibe la solicitud GET para una URL corta.
2. Balanceador de Carga: Distribuye las solicitudes de lectura a las instancias de la API US.
3. API US (Servicio de Lectura):
   • Extrae el código corto de la ruta de la URL.
   • Búsqueda en Caché: Comprueba una caché distribuida (ej. Redis Cluster) en busca del código corto.
     • Acertada en Caché: Si se encuentra, recupera la URL original y devuelve una respuesta de redirección HTTP 301/302.
     • Errónea en Caché: Si no se encuentra, consulta el almacén de datos principal.
   • Búsqueda en Almacén de Datos: Consulta el almacén de datos principal para obtener la URL original asociada con el código corto.
   • Actualización de Caché: Si se encuentra en el almacén de datos, la URL original se agrega a la caché para futuras solicitudes.
   • Redirección: Devuelve una respuesta de redirección HTTP 301/302 con la URL original.
   • Manejo de Errores: Si no se encuentra, devuelve un 404 Not Found.
4. Analíticas de Clics (Asíncrono): Un servicio o mecanismo separado (ver Sección 7) registra asíncronamente los eventos de clic.

Compromisos:

• Separación de Responsabilidades: Separar los servicios de lectura y escritura permite escalar y optimizar de forma independiente. La ruta de lectura está optimizada para baja latencia y alto rendimiento.
• API Gateway/Balanceador de Carga: Introduce un único punto de fallo si no está configurado para alta disponibilidad, pero es esencial para escalar y gestionar el tráfico.
• Penalización por Error en Caché: Un error en caché incurre en mayor latencia debido a la consulta del almacén de datos, pero esto se mitiga con una caché grande y una alta tasa de aciertos.

2. Estrategia de Generación de Códigos Cortos

Estrategia: Codificación Base62 con un Contador/Generador de ID.

1. Generación de ID: Utilizaremos un servicio de generación de ID distribuido (ej. tipo Snowflake o un servicio dedicado usando ZooKeeper/etcd) para generar enteros de 64 bits únicos y monótonamente crecientes. Esto asegura la unicidad y evita colisiones en la fuente.
   • Compromiso: Requiere un servicio de generación de ID de alto rendimiento y alta disponibilidad. Si falla, no se pueden crear nuevos enlaces cortos.
2. Codificación Base62: Cada ID de 64 bits generado se convierte en una cadena Base62 (0-9, a-z, A-Z). Un ID de 64 bits puede representar hasta 2^64 valores únicos. Los primeros 6 caracteres pueden representar ~68 mil millones de valores únicos (62^6), y 7 caracteres pueden representar ~4.1 billones (62^7). Para 30 mil millones de enlaces durante 5 años, 7 caracteres son suficientes y proporcionan amplio margen para el crecimiento.
   • Compromiso: La codificación Base62 es ligeramente más compleja que el hash simple, pero proporciona URL más cortas y evita la adivinación en comparación con los ID secuenciales.
3. Alias Personalizados:
   • Cuando un usuario solicita un alias personalizado (ej. /mi-enlace), el servicio de escritura primero comprueba si el alias ya está ocupado en una tabla/índice dedicado en el almacén de datos (ej. tabla custom_aliases que mapea alias -> short_code).
   • Si el alias está disponible, se reserva y se asocia con el código corto recién generado.
   • Si el alias está ocupado, la API devuelve un error al usuario.
   • Manejo de Colisiones: La generación de ID y la codificación Base62 aseguran la unicidad para los códigos cortos generados. Los alias personalizados se manejan mediante una operación separada y atómica de verificación y establecimiento en el almacén de datos para evitar colisiones.
   • Compromiso: Las búsquedas de alias personalizados añaden una pequeña sobrecarga a la ruta de escritura. La disponibilidad de alias personalizados no está garantizada.

Garantía de Unicidad: Lograda por el generador de ID distribuido. Cada ID es único, y su representación Base62 también será única.

No Adivinable: Los ID codificados en Base62 no son secuenciales y no revelan el orden de creación ni el número total de enlaces. Son cadenas con apariencia aleatoria.

3. Modelo de Datos y Almacén(es) de Datos

Elección del Almacén de Datos: Un almacén de datos clave-valor NoSQL distribuido (ej. Cassandra, DynamoDB, o una BD relacional shardeada como Vitess) para el mapeo principal de enlaces, y un sistema separado para analíticas.

Almacén de Datos Principal (Mapeo de Enlaces):

• Esquema:

  • Tabla/colección links:
    • short_code (Clave Primaria, Cadena, ej. "aBcDeFg")
    • original_url (Cadena)
    • created_at (Timestamp)
    • user_id (Opcional, para propiedad/gestión)
  • Tabla/colección custom_aliases:
    • alias (Clave Primaria, Cadena, ej. "mi-enlace")
    • short_code (Cadena, Clave Externa a links.short_code)

• Justificación del Tipo de Almacén de Datos: Se elige un almacén de datos clave-valor NoSQL distribuido por su alta disponibilidad, escalabilidad horizontal y excelente rendimiento de lectura para búsquedas por clave, lo cual es crítico para la ruta de redirección. Puede manejar la escala masiva de 30 mil millones de entradas.

• Estimación de Capacidad/Almacenamiento:

  • Tabla Links: 30 mil millones de entradas.
    • short_code: ~7 bytes (Base62, 7 caracteres)
    • original_url: Promedio 100 bytes (puede variar significativamente, asumir promedio)
    • created_at, user_id: ~10 bytes
    • Total por entrada: ~117 bytes. Redondeemos a 150 bytes para sobrecarga y replicación.
    • Almacenamiento total: 30 mil millones * 150 bytes = 4.5 * 10^12 bytes = 4.5 TB.
  • Tabla Custom Aliases: Asumir que el 10% de los enlaces tienen alias personalizados (3 mil millones).
    • alias: Promedio 15 bytes (más corto que las URL largas).
    • short_code: ~7 bytes.
    • Total por entrada: ~22 bytes. Redondeemos a 50 bytes para sobrecarga.
    • Almacenamiento total: 3 mil millones * 50 bytes = 150 * 10^9 bytes = 0.15 TB.
  • Almacenamiento Principal Total: ~4.65 TB. Esto es manejable para sistemas NoSQL distribuidos.

• Particionamiento/Sharding: El almacén de datos se shardeá por short_code (para la tabla links) y alias (para la tabla custom_aliases). Esto permite una distribución uniforme de datos y carga entre nodos.

Compromisos:

• NoSQL vs. SQL: Se prefiere un almacén NoSQL por su flexibilidad de esquema y escalabilidad horizontal. Una BD relacional podría funcionar pero requeriría una gestión de sharding más compleja (ej. Vitess).
• Redundancia de Datos: Los almacenes NoSQL típicamente replican datos para disponibilidad, aumentando los requisitos de almacenamiento pero mejorando la tolerancia a fallos.
• Tabla de Alias Personalizados: Se utiliza una tabla separada para comprobar eficientemente la disponibilidad de alias sin escanear la tabla principal de links, lo cual sería ineficiente.

4. Estrategia de Caché

Estrategia: Caché Distribuida en Memoria (ej. Redis Cluster, Memcached).

• Qué Cachéar: Mapeos de short_code a original_url accedidos frecuentemente.
• Clave de Caché: short_code (ej. "aBcDeFg")
• Valor de Caché: original_url (ej. "https://www.verylongurl.com/...")
• Tamaño de Caché: Dimensionado para contener una porción significativa de los enlaces