Cuando necesitemos una nueva clave, podemos tomar uno de los IDs ya generados. Este enfoque puede hacer las cosas más rápidas ya que mientras llega una nueva solicitud, no necesitamos crear un ID, asegurar su unicidad, etc. UGS asegurará que todos los IDs son únicos, y pueden ser almacenados en una base de datos para que los IDs no necesiten ser generados cada vez.

Como necesitamos un byte para almacenar un carácter, podemos almacenar todas estas claves en:

6 (caracteres) * 68.7B (claves únicas) ~= 412 GB.

★Disponibilidad &Fiabilidad:

Si mantenemos una copia de UGS, es un único punto de fallo. Por lo tanto, tenemos que hacer una réplica de UGS. Si el servidor primario muere, el secundario puede atender las peticiones de los usuarios.

Cada servidor UGS puede almacenar en caché algunas claves de la key-DB. Esto puede acelerar las cosas. Pero, tenemos que tener cuidado; si un servidor muere antes de consumir todas las claves, perderemos esas claves. Pero, podemos asumir, que esto es aceptable ya que tenemos casi 68B claves únicas de seis letras.

Para garantizar la disponibilidad, tenemos que asegurarnos de eliminar un único punto de fallo en el sistema. La replicación de datos eliminará un único punto de fallo y proporcionará una copia de seguridad. Podemos mantener múltiples réplicas para garantizar la fiabilidad del servidor de base de datos. Y además, para un servicio ininterrumpido, otros servidores también necesitan copias.

★DataStorage:

En este sistema, necesitamos almacenar miles de millones de registros. Cada objeto que guardamos es posiblemente menos de 1 KB. Los datos de una URL no están relacionados con los de otra. Por lo tanto, podemos utilizar una base de datos NoSQL como Cassandra, DynamoDB, etc. Una elección NoSQL sería más fácil de escalar, que es uno de nuestros requisitos.

★ Escalabilidad:

Para soportar miles de millones de URLs, necesitamos particionar nuestra base de datos para dividir y almacenar nuestros datos en diferentes servidores de DB.

i) Podemos particionar la base de datos basada en la primera letra de la clave hash. Podemos poner las claves que comienzan con ‘A’ en un servidor, ‘B’ en otro servidor. Esto se llama partición basada en el rango.

El problema con este enfoque es que puede llevar a una partición desequilibrada. Por ejemplo, hay muy pocas palabras que empiecen por ‘Z.’ Por otro lado; podemos tener demasiadas URLs que empiecen por la letra ‘E.’

Podemos combinar las letras que aparecen con menos frecuencia en una sola partición de la base de datos.

ii) También podemos hacer una partición basada en el hash de los objetos que estamos almacenando. Podemos tomar el hash de la clave para determinar la partición en la que podemos almacenar el objeto de datos. La función hash generará un número de servidor, y almacenaremos la clave en ese servidor. Este proceso puede hacer que la distribución sea más aleatoria. Esto es el Particionamiento Basado en Hash.

Si este enfoque todavía conduce a particiones sobrecargadas, tenemos que utilizar el Hashing Consistente.

★ Caché:

Podemos almacenar en caché las URLs a las que los usuarios acceden con frecuencia. Los servidores UGS, antes de hacer una consulta a la base de datos, pueden comprobar si la caché tiene la URL deseada. Entonces no es necesario hacer la consulta de nuevo.

¿Qué pasará cuando la caché esté llena? Podemos sustituir un enlace antiguo no utilizado por una URL más nueva o popular. Podemos elegir la política de desalojo de la caché Least Recently Used (LRU) para nuestro sistema. En esta política, eliminamos primero la URL menos utilizada recientemente.

★ Equilibrador de carga:

Podemos añadir una capa de equilibrio de carga en diferentes lugares de nuestro sistema, delante del servidor de acortamiento de URL, la base de datos y los servidores de caché.

Podemos utilizar un enfoque simple de Round Robin para la distribución de solicitudes. En este enfoque, LB distribuye las peticiones entrantes de forma equitativa entre los servidores backend. Este enfoque de LB es sencillo de implementar. Si un servidor está muerto, el LB dejará de enviarle tráfico.

Problema: Si un servidor está sobrecargado, el LB no dejará de enviar una nueva petición a ese servidor en este enfoque. Podríamos necesitar un LB inteligente más adelante.

★ Expiración de enlaces después de una duración:

Si se alcanza el tiempo de expiración de una URL, ¿qué pasaría con el enlace?

Podemos buscar en nuestros datastores y eliminarlos. El problema aquí es que si elegimos buscar los enlaces caducados para eliminarlos de nuestro almacén de datos, pondría mucha presión en nuestra base de datos.

Podemos hacerlo de otra manera. Podemos eliminar lentamente los enlaces caducados periódicamente. Incluso si algunos enlaces muertos viven más tiempo, nunca deberían ser devueltos a los usuarios.

Si un usuario intenta acceder a un enlace caducado, podemos eliminar el enlace y devolver un error al usuario. Se puede ejecutar un proceso de limpieza periódico para eliminar los enlaces caducados de nuestra base de datos. Como el almacenamiento es cada vez más barato, algunos enlaces podrían permanecer allí incluso si nos perdemos mientras la limpieza.

Después de eliminar el enlace, podemos ponerlo de nuevo en nuestra base de datos para su reutilización.

★ Seguridad:

Podemos almacenar el tipo de acceso (público/privado) con cada URL en la base de datos. Si un usuario intenta acceder a una URL, que no tiene permiso, el sistema puede enviar un error (HTTP 401) de vuelta.