Wanneer we een nieuwe sleutel nodig hebben, kunnen we een van de reeds gegenereerde ID’s nemen. Deze aanpak kan dingen sneller maken, want als er een nieuw verzoek komt, hoeven we geen ID te maken, de uniciteit ervan te verzekeren, enz. UGS zal ervoor zorgen dat alle ID’s uniek zijn, en ze kunnen worden opgeslagen in een database, zodat de ID’s niet elke keer hoeven te worden gegenereerd.

Aangezien we één byte nodig hebben om één karakter op te slaan, kunnen we al deze sleutels opslaan in:

6 (karakters) * 68.7B (unieke sleutels) ~= 412 GB.

★Beschikbaarheid & Betrouwbaarheid:

Als we één kopie van UGS bewaren, is dat een single point of failure. Dus, we moeten een replica van UGS maken. Als de primaire server uitvalt, kan de secundaire de verzoeken van de gebruikers afhandelen.

Elke UGS-server kan een aantal sleutels uit de key-DB in de cache opslaan. Het kan dingen versnellen. Maar we moeten voorzichtig zijn; als een server sterft voordat alle sleutels zijn verbruikt, zullen we die sleutels verliezen. Maar we kunnen aannemen dat dit acceptabel is, omdat we bijna 68B unieke zes-letter sleutels hebben.

Om beschikbaarheid te garanderen, moeten we ervoor zorgen om een enkel punt van falen in het systeem te verwijderen. Replicatie voor gegevens zal een enkel punt van mislukking verwijderen en back-up verstrekken. We kunnen meerdere replicaties houden om de betrouwbaarheid van de databaseserver te garanderen. En voor een ononderbroken service hebben andere servers ook kopieën nodig.

★DataStorage:

In dit systeem moeten we miljarden records opslaan. Elk object dat we bewaren is mogelijk minder dan 1 KB. Een URL-gegevens is niet gerelateerd aan een andere. Dus kunnen we een NoSQL database gebruiken zoals Cassandra, DynamoDB, enz. Een NoSQL keuze zou gemakkelijker te schalen zijn, wat een van onze eisen is.

★ Schaalbaarheid:

Voor het ondersteunen van miljarden URL’s, moeten we onze database partitioneren om onze gegevens te verdelen en op te slaan in verschillende DB-servers.

i) We kunnen de database partitioneren op basis van de eerste letter van de hash-sleutel. We kunnen sleutels beginnend met ‘A’ in een server zetten, ‘B’ in een andere server. Dit wordt Range Based Partitioning genoemd.

Het probleem met deze aanpak is dat het kan leiden tot onevenwichtige partitionering. Er zijn bijvoorbeeld maar heel weinig woorden die beginnen met ‘Z.’ Aan de andere kant hebben we misschien te veel URL’s die beginnen met de letter ‘E.’

We kunnen minder vaak voorkomende letters combineren in één databasepartitie.

ii) We kunnen ook partitioneren op basis van de hash van de objecten die we opslaan. We kunnen de hash van de sleutel nemen om de partitie te bepalen waarin we het data-object kunnen opslaan. De hashfunctie zal een servernummer genereren, en we zullen de sleutel in die server opslaan. Dit proces kan de verdeling willekeuriger maken. Dit is Hash-Based Partitioning.

Als deze aanpak nog steeds leidt tot overbelaste partities, moeten we Consistent Hashing gebruiken.

★ Cache:

We kunnen URL’s cachen die vaak door de gebruikers worden bezocht. De UGS-servers kunnen, voordat ze een query naar de database doen, controleren of de cache de gewenste URL bevat. Dan is het niet nodig om de query opnieuw te maken.

Wat zal er gebeuren als de cache vol is? We kunnen een oudere niet gebruikte link vervangen door een nieuwere of populaire URL. We kunnen kiezen voor de Least Recently Used (LRU) cache eviction policy voor ons systeem. Bij dit beleid verwijderen we de minst recent gebruikte URL als eerste.

★ Load balancer:

We kunnen een load balancing laag toevoegen op verschillende plaatsen in ons systeem, voor de URL verkortingsserver, database, en cache servers.

We kunnen een eenvoudige Round Robin aanpak gebruiken voor het verdelen van verzoeken. In deze aanpak verdeelt LB de inkomende verzoeken gelijkmatig over de backend servers. Deze aanpak van LB is eenvoudig te implementeren. Als een server dood is, stopt LB met het versturen van verkeer naar die server.

Probleem: als een server overbelast is, stopt LB in deze aanpak niet met het versturen van een nieuw verzoek naar die server. Misschien hebben we later een intelligente LB nodig.

★ Verval van de link na een bepaalde tijd:

Als de vervaltijd voor een URL is bereikt, wat zou er dan met de link gebeuren?

We kunnen in onze datastores zoeken en ze verwijderen. Het probleem hier is dat als we ervoor kiezen om te zoeken naar verlopen links om ze te verwijderen uit onze data store, het veel druk zou leggen op onze database.

We kunnen het ook op een andere manier doen. We kunnen langzaam periodiek verlopen links verwijderen. Zelfs als sommige dode links langer leven, mogen ze nooit aan gebruikers worden teruggegeven.

Als een gebruiker probeert een verlopen link te openen, kunnen we de link verwijderen en een foutmelding aan de gebruiker teruggeven. Een periodiek opruimproces kan worden uitgevoerd om verlopen links uit onze database te verwijderen. Omdat opslag steeds goedkoper wordt, kunnen sommige links daar blijven, zelfs als we tijdens het opschonen missen.

Na het verwijderen van de link, kunnen we deze weer terugplaatsen in onze database voor hergebruik.

★ Veiligheid:

We kunnen het toegangstype (publiek/privaat) bij elke URL in de database opslaan. Als een gebruiker een URL probeert te benaderen waarvoor hij geen toestemming heeft, kan het systeem een foutmelding (HTTP 401) terugsturen.