Lorsque nous avons besoin d’une nouvelle clé, nous pouvons prendre une des ID déjà générées. Cette approche peut rendre les choses plus rapides car chaque fois qu’une nouvelle demande arrive, nous n’avons pas besoin de créer un ID, d’assurer son unicité, etc. UGS s’assurera que tous les ID sont uniques, et ils peuvent être stockés dans une base de données afin que les ID n’aient pas besoin d’être générés à chaque fois.

Comme nous avons besoin d’un octet pour stocker un caractère, nous pouvons stocker toutes ces clés dans :

6 (caractères) * 68.7B (clés uniques) ~= 412 Go.

★Disponibilité & Fiabilité:

Si nous gardons une seule copie de UGS, c’est un point de défaillance unique. Donc, nous devons faire une réplique de UGS. Si le serveur primaire meurt, le secondaire peut traiter les demandes des utilisateurs.

Chaque serveur UGS peut mettre en cache certaines clés de key-DB. Cela peut accélérer les choses. Mais, nous devons être prudents ; si un serveur meurt avant d’avoir consommé toutes les clés, nous perdrons ces clés. Mais, nous pouvons supposer, c’est acceptable puisque nous avons presque 68B clés uniques de six lettres.

Pour assurer la disponibilité, nous devons nous assurer de supprimer un point unique de défaillance dans le système. La réplication pour les données supprimera un point unique de défaillance et fournira une sauvegarde. Nous pouvons garder plusieurs réplications pour assurer la fiabilité du serveur de base de données. Et aussi, pour un service ininterrompu, les autres serveurs ont également besoin de copies.

★DataStorage:

Dans ce système, nous devons stocker des milliards d’enregistrements. Chaque objet que nous conservons est peut-être inférieur à 1 KB. Une donnée URL n’est pas liée à une autre. Ainsi, nous pouvons utiliser une base de données NoSQL comme Cassandra, DynamoDB, etc. Un choix NoSQL serait plus facile à faire évoluer, ce qui est l’une de nos exigences.

★ Scalability:

Pour supporter des milliards d’URL, nous devons partitionner notre base de données pour diviser et stocker nos données dans différents serveurs DB.

i) Nous pouvons partitionner la base de données en fonction de la première lettre de la clé de hachage. Nous pouvons mettre les clés commençant par ‘A’ dans un serveur, ‘B’ dans un autre serveur. C’est ce qu’on appelle le partitionnement basé sur la plage.

Le problème avec cette approche est qu’elle peut conduire à un partitionnement déséquilibré. Par exemple, il y a très peu de mots commençant par ‘Z’. D’autre part ; nous pouvons avoir trop d’URL qui commencent par la lettre ‘E’.’

Nous pouvons combiner des lettres moins fréquentes dans une partition de base de données.

ii) Nous pouvons également partitionner en fonction du hachage des objets que nous stockons. Nous pouvons prendre le hachage de la clé pour déterminer la partition dans laquelle nous pouvons stocker l’objet de données. La fonction de hachage génère un numéro de serveur, et nous stockons la clé dans ce serveur. Ce processus peut rendre la distribution plus aléatoire. C’est le partitionnement basé sur le hachage.

Si cette approche conduit encore à des partitions surchargées, nous devons utiliser le hachage cohérent.

★ Cache:

Nous pouvons mettre en cache les URL qui sont fréquemment consultées par les utilisateurs. Les serveurs UGS, avant de faire une requête à la base de données, peuvent vérifier si le cache contient l’URL désirée. Ensuite, il n’a pas besoin d’effectuer la requête à nouveau.

Que se passera-t-il lorsque le cache sera plein ? Nous pouvons remplacer un ancien lien non utilisé par une URL plus récente ou populaire. Nous pouvons choisir la politique d’éviction du cache LRU (Least Recently Used) pour notre système. Dans cette politique, nous supprimons d’abord l’URL la moins récemment utilisée.

★ Équilibreur de charge:

Nous pouvons ajouter une couche d’équilibrage de charge à différents endroits dans notre système, devant le serveur de raccourcissement d’URL, la base de données et les serveurs de cache.

Nous pouvons utiliser une approche simple Round Robin pour la distribution des demandes. Dans cette approche, LB distribue les demandes entrantes de manière égale entre les serveurs backend. Cette approche de LB est simple à mettre en œuvre. Si un serveur est mort, le LB cessera d’envoyer tout trafic vers lui.

Problème : si un serveur est surchargé, le LB ne cessera pas d’envoyer une nouvelle demande à ce serveur dans cette approche. Nous pourrions avoir besoin d’un LB intelligent plus tard.

★ Expiration du lien après une durée:

Si la durée d’expiration est atteinte pour une URL, que se passerait-il pour le lien?

Nous pouvons chercher dans nos datastores et les supprimer. Le problème ici est que si nous choisissions de rechercher les liens expirés pour les supprimer de notre magasin de données, cela mettrait beaucoup de pression sur notre base de données.

Nous pouvons le faire d’une autre manière. Nous pouvons supprimer lentement les liens expirés périodiquement. Même si certains liens morts vivent plus longtemps, il ne devrait jamais être renvoyé aux utilisateurs.

Si un utilisateur essaie d’accéder à un lien expiré, nous pouvons supprimer le lien et renvoyer une erreur à l’utilisateur. Un processus de nettoyage périodique peut être exécuté pour supprimer les liens expirés de notre base de données. Comme le stockage devient moins cher, certains liens pourraient rester là même si nous manquons pendant le nettoyage.

Après avoir retiré le lien, nous pouvons le remettre dans notre base de données pour le réutiliser.

★ Sécurité:

Nous pouvons stocker le type d’accès (public/privé) avec chaque URL dans la base de données. Si un utilisateur essaie d’accéder à une URL, dont il n’a pas la permission, le système peut renvoyer une erreur (HTTP 401).