Kdykoli potřebujeme nový klíč, můžeme vzít jedno z již vygenerovaných ID. Tento přístup může urychlit práci, protože při příchodu nového požadavku nemusíme vytvářet ID, zajišťovat jeho jedinečnost atd. UGS zajistí, aby všechna ID byla jedinečná, a lze je uložit do databáze, takže ID není třeba pokaždé generovat.

Jelikož k uložení jednoho znaku potřebujeme jeden bajt, můžeme všechny tyto klíče uložit do:

6 (znaků) * 68. V případě, že se jedná o jedinečné ID, můžeme je uložit do databáze.7B (unikátní klíče) ~= 412 GB.

★Dostupnost & Spolehlivost:

Pokud uchováváme jednu kopii UGS, jedná se o jediný bod selhání. Musíme tedy vytvořit repliku UGS. Pokud primární server zemře, sekundární může vyřizovat požadavky uživatelů.

Každý server UGS může ukládat do mezipaměti některé klíče z databáze klíčů. Může to urychlit práci. Musíme však být opatrní; pokud jeden server zemře dříve, než spotřebuje všechny klíče, o tyto klíče přijdeme. Ale můžeme předpokládat, že je to přijatelné, protože máme téměř 68B unikátních šestipísmenných klíčů.

Pro zajištění dostupnosti musíme zajistit odstranění jediného bodu selhání v systému. Replikace pro data odstraní jediný bod selhání a zajistí zálohování. Pro zajištění spolehlivosti databázového serveru můžeme zachovat více replikací. A také pro nepřetržitou službu potřebují kopie i ostatní servery.

★Úložiště dat:

V tomto systému potřebujeme ukládat miliardy záznamů. Každý objekt, který uchováváme, má možná méně než 1 KB. Jeden údaj adresy URL nesouvisí s jiným. Můžeme tedy použít databázi NoSQL, jako je Cassandra, DynamoDB atd. Volba NoSQL by byla jednodušší na škálování, což je jeden z našich požadavků.

★ Škálovatelnost:

Pro podporu miliard URL potřebujeme rozdělit naši databázi, abychom rozdělili a uložili naše data na různé servery DB.

i) Databázi můžeme rozdělit na základě prvního písmene hash klíče. Klíče začínající na ‚A‘ můžeme umístit na jeden server, ‚B‘ na jiný server. Tomu se říká rozdělení na základě rozsahu.

Problémem tohoto přístupu je, že může vést k nevyváženému rozdělení. Například existuje velmi málo slov začínajících na ‚Z‘. Na druhou stranu; můžeme mít příliš mnoho adres URL, které začínají na písmeno ‚E‘.

Můžeme spojit méně často se vyskytující písmena do jednoho rozdělení databáze.

ii) Můžeme také rozdělit na základě hashe ukládaných objektů. Můžeme vycházet z hashe klíče, abychom určili oddíl, do kterého můžeme datový objekt uložit. Hashovací funkce vygeneruje číslo serveru a klíč uložíme do tohoto serveru. Tímto postupem můžeme dosáhnout náhodnějšího rozdělení. Jedná se o rozdělení na základě hashe.

Pokud tento přístup stále vede k přetíženým oddílům, musíme použít konzistentní rozdělení na základě hashe.

★ Cache:

Můžeme ukládat do mezipaměti adresy URL, ke kterým uživatelé často přistupují. Servery UGS mohou před provedením dotazu do databáze zkontrolovat, zda se v mezipaměti nachází požadovaná adresa URL. Pak nemusí dotaz provádět znovu.

Co se stane, když je mezipaměť plná? Starší nepoužívaný odkaz můžeme nahradit novějším nebo oblíbeným URL. Pro náš systém můžeme zvolit politiku vypuštění nejméně nedávno použité mezipaměti (LRU). V této politice odstraníme jako první nejméně používanou adresu URL.

★ Vyvažovač zátěže:

Můžeme přidat vrstvu pro vyvažování zátěže na různá místa v našem systému, před server pro zkracování adres URL, databázi a servery cache.

Můžeme použít jednoduchý přístup Round Robin pro distribuci požadavků. V tomto přístupu LB rozděluje příchozí požadavky rovnoměrně mezi backendové servery. Tento přístup LB je jednoduchý na implementaci. Pokud je server mrtvý, LB na něj přestane posílat jakýkoli provoz.

Problém: Pokud je server přetížen, LB v tomto přístupu nepřestane na tento server posílat nové požadavky. Později bychom mohli potřebovat inteligentní LB.

★ Vypršení platnosti odkazu po uplynutí doby trvání:

Pokud je u URL dosažena doba platnosti, co by se s odkazem stalo?

Můžeme je vyhledat v našich datových úložištích a odstranit je. Problém je v tom, že pokud bychom se rozhodli vyhledávat odkazy, jejichž platnost vypršela, a odstranit je z našeho datového skladu, znamenalo by to velký nápor na naši databázi.

Můžeme to udělat jinak. Můžeme pravidelně pomalu odstraňovat prošlé odkazy. I když některé mrtvé odkazy žijí déle, neměly by se uživatelům nikdy vrátit.

Pokud se uživatel pokusí přistoupit k prošlému odkazu, můžeme odkaz odstranit a vrátit uživateli chybu. Pro odstranění prošlých odkazů z naší databáze může být spuštěn proces pravidelného čištění. Vzhledem k tomu, že úložiště je stále levnější, některé odkazy tam mohou zůstat, i když je při čištění vynecháme.

Po odstranění odkazu jej můžeme vrátit zpět do naší databáze pro opětovné použití.

★ Zabezpečení:

K každé adrese URL v databázi můžeme uložit typ přístupu (veřejný/soukromý). Pokud se uživatel pokusí přistoupit na URL, ke kterému nemá oprávnění, může systém poslat zpět chybu (HTTP 401).