Gdy potrzebujemy nowego klucza, możemy wziąć jeden z już wygenerowanych identyfikatorów. Takie podejście może przyspieszyć pracę, ponieważ podczas gdy przychodzi nowe żądanie, nie musimy tworzyć identyfikatora, zapewniać jego unikalności itp. UGS zapewni, że wszystkie identyfikatory są unikalne, i mogą być przechowywane w bazie danych, tak że identyfikatory nie muszą być generowane za każdym razem.

Jako że potrzebujemy jednego bajtu do przechowywania jednego znaku, możemy przechowywać wszystkie te klucze w:

6 (znaki) * 68.7B (unikalne klucze) ~= 412 GB.

★Dostępność & Niezawodność:

Jeśli utrzymujemy jedną kopię UGS, jest to pojedynczy punkt awarii. Musimy więc stworzyć replikę UGS. Jeśli główny serwer umrze, drugi może obsługiwać żądania użytkowników.

Każdy serwer UGS może buforować niektóre klucze z key-DB. To może przyspieszyć działanie. Ale musimy być ostrożni; jeśli jeden z serwerów umrze przed zużyciem wszystkich kluczy, stracimy te klucze. Ale, możemy założyć, że jest to do zaakceptowania, ponieważ mamy prawie 68B unikalnych sześcioliterowych kluczy.

Aby zapewnić dostępność, musimy zadbać o usunięcie pojedynczego punktu awarii w systemie. Replikacja dla danych usunie pojedynczy punkt awarii i zapewni kopię zapasową. Możemy utrzymywać wiele replikacji, aby zapewnić niezawodność serwera bazy danych. A także, dla zapewnienia nieprzerwanej usługi, inne serwery również potrzebują kopii.

★DataStorage:

W tym systemie, musimy przechowywać miliardy rekordów. Każdy obiekt, który przechowujemy jest prawdopodobnie mniejszy niż 1 KB. Dane z jednego adresu URL nie są powiązane z innymi. Możemy więc użyć bazy danych NoSQL, takiej jak Cassandra, DynamoDB itp. Wybór NoSQL byłby łatwiejszy do skalowania, co jest jednym z naszych wymagań.

★ Skalowalność:

Dla obsługi miliardów adresów URL, musimy partycjonować naszą bazę danych, aby podzielić i przechowywać nasze dane na różnych serwerach DB.

i) Możemy podzielić bazę danych na podstawie pierwszej litery klucza hash. Możemy umieścić klucze zaczynające się od 'A’ na jednym serwerze, 'B’ na innym. Nazywa się to Range Based Partitioning.

Problem z tym podejściem polega na tym, że może ono prowadzić do niezrównoważonego partycjonowania. Na przykład, istnieje bardzo mało słów zaczynających się na 'Z.’ Z drugiej strony, możemy mieć zbyt wiele adresów URL, które zaczynają się na literę 'E.’

Możemy połączyć rzadziej występujące litery w jedną partycję bazy danych.

ii) Możemy również partycjonować w oparciu o hash przechowywanych obiektów. Możemy przyjąć hash klucza do określenia partycji, w której możemy przechowywać dany obiekt danych. Funkcja haszująca wygeneruje numer serwera, a my będziemy przechowywać klucz w tym serwerze. Ten proces może sprawić, że dystrybucja będzie bardziej losowa. To jest Hash-Based Partitioning.

Jeśli to podejście nadal prowadzi do przeciążenia partycji, musimy użyć Consistent Hashing.

★ Cache:

Możemy buforować adresy URL, które są często odwiedzane przez użytkowników. Serwery UGS, przed wykonaniem zapytania do bazy danych, mogą sprawdzić, czy w cache’u znajduje się żądany adres URL. Wtedy nie musi wykonywać ponownego zapytania.

Co się stanie, gdy cache się zapełni? Możemy zastąpić starszy, nieużywany link nowszym lub popularnym adresem URL. Możemy wybrać dla naszego systemu politykę eksmisji z pamięci podręcznej LRU (Least Recently Used). W tej polityce, usuwamy ostatnio używany URL jako pierwszy.

★ Load balancer:

Możemy dodać warstwę równoważenia obciążenia w różnych miejscach naszego systemu, przed serwerem skracania URL, bazą danych i serwerami cache.

Możemy użyć prostego podejścia Round Robin do dystrybucji żądań. W tym podejściu, LB dystrybuuje przychodzące żądania równo pomiędzy serwerami backend. To podejście LB jest proste do zaimplementowania. Jeśli serwer jest martwy, LB przestanie wysyłać do niego jakikolwiek ruch.

Problem: Jeśli serwer jest przeciążony, LB nie przestanie wysyłać nowego żądania do tego serwera w tym podejściu. Możemy potrzebować inteligentnego LB później.

★ Wygaśnięcie linku po czasie trwania:

Jeśli czas wygaśnięcia zostanie osiągnięty dla adresu URL, co stanie się z linkiem?

Możemy szukać w naszych magazynach danych i usuwać je. Problem polega na tym, że gdybyśmy zdecydowali się wyszukiwać wygasłe linki, aby usunąć je z naszego magazynu danych, spowodowałoby to duży nacisk na naszą bazę danych.

Możemy to zrobić w inny sposób. Możemy powoli usuwać wygasłe linki okresowo. Nawet jeśli niektóre martwe linki żyją dłużej, nigdy nie powinny być zwracane użytkownikom.

Jeśli użytkownik próbuje uzyskać dostęp do wygasłego linku, możemy usunąć link i zwrócić błąd do użytkownika. Okresowy proces czyszczenia może zostać uruchomiony w celu usunięcia wygasłych linków z naszej bazy danych. Ponieważ pamięć masowa staje się coraz tańsza, niektóre linki mogą tam pozostać, nawet jeśli przegapimy proces czyszczenia.

Po usunięciu linku, możemy umieścić go z powrotem w naszej bazie danych do ponownego użycia.

★ Bezpieczeństwo:

Możemy przechowywać typ dostępu (publiczny/prywatny) z każdym adresem URL w bazie danych. Jeśli użytkownik próbuje uzyskać dostęp do adresu URL, do którego nie ma uprawnień, system może wysłać błąd (HTTP 401) z powrotem.

.