Amikor új kulcsra van szükségünk, a már generált azonosítók egyikét használhatjuk. Ez a megközelítés felgyorsíthatja a dolgokat, mivel amíg egy új kérés érkezik, nem kell létrehoznunk egy azonosítót, biztosítanunk annak egyediségét stb. Az UGS biztosítja, hogy minden azonosító egyedi legyen, és ezeket egy adatbázisban tárolhatjuk, így az azonosítókat nem kell minden alkalommal generálni.

Mivel egy karakter tárolásához egy bájtra van szükségünk, az összes ilyen kulcsot tárolhatjuk:

6 (karakter) * 68.7B (egyedi kulcsok) ~= 412 GB.

★Availability & Reliability:

Ha egy példányt tartunk az UGS-ből, az egyetlen hibapontot jelent. Tehát az UGS-ről egy másolatot kell készítenünk. Ha az elsődleges szerver meghal, a másodlagos szerver képes kezelni a felhasználók kéréseit.

Minden UGS szerver képes néhány kulcsot gyorsítótárba helyezni a kulcs-DB-ből. Ez felgyorsíthatja a dolgokat. De óvatosnak kell lennünk; ha az egyik szerver meghal, mielőtt az összes kulcsot elfogyasztaná, elveszítjük ezeket a kulcsokat. De feltételezhetjük, hogy ez elfogadható, mivel közel 68B egyedi hatbetűs kulcsunk van.

A rendelkezésre állás biztosítása érdekében gondoskodnunk kell arról, hogy a rendszerben ne legyen egyetlen hibapont. A Replication for Data eltávolítja az egyetlen hibapontot, és biztonsági mentést biztosít. Az adatbázis-kiszolgáló megbízhatóságának biztosítása érdekében többszörös replikációt tarthatunk fenn. És a megszakítás nélküli szolgáltatáshoz más szervereknek is szükségük van másolatokra.

★Adattárolás:

A rendszerben több milliárd rekordot kell tárolnunk. Minden egyes objektum, amit tárolunk, valószínűleg kevesebb, mint 1 KB. Az egyik URL-adat nem kapcsolódik a másikhoz. Ezért használhatunk egy NoSQL adatbázist, mint például a Cassandra, DynamoDB stb. Egy NoSQL választás könnyebben skálázható lenne, ami az egyik követelményünk.

★ Skálázhatóság:

Az URL-ek milliárdjainak támogatásához partícionálnunk kell az adatbázisunkat, hogy az adatainkat különböző DB szerverekre osszuk és tároljuk.

i) Az adatbázist a hash kulcs első betűje alapján particionálhatjuk. Az ‘A’-val kezdődő kulcsokat az egyik szerverre, a ‘B’-t egy másik szerverre helyezhetjük. Ezt nevezzük tartomány alapú particionálásnak.

A probléma ezzel a megközelítéssel az, hogy kiegyensúlyozatlan particionáláshoz vezethet. Például nagyon kevés ‘Z’ betűvel kezdődő szó van. Másrészt; lehet, hogy túl sok olyan URL-ünk van, amely ‘E’ betűvel kezdődik.’

A ritkábban előforduló betűket egy adatbázis-partícióban egyesíthetjük.

ii) Partícionálhatunk a tárolt objektumok hash-ja alapján is. A kulcs hash-ja alapján meghatározhatjuk, hogy melyik partícióban tárolhatjuk az adatobjektumot. A hash függvény generál egy kiszolgálószámot, és a kulcsot ezen a kiszolgálón fogjuk tárolni. Ez az eljárás véletlenszerűbbé teheti az elosztást. Ez a Hash-alapú particionálás.

Ha ez a megközelítés még mindig túlterhelt partíciókhoz vezet, akkor a konzisztens Hashinget kell használnunk.

★ Cache:

A felhasználók által gyakran látogatott URL-címeket gyorsítótárba helyezhetjük. Az UGS szerverek az adatbázis lekérdezése előtt ellenőrizhetik, hogy a gyorsítótárban megtalálható-e a kívánt URL. Ekkor nem kell újra elvégezni a lekérdezést.

Mi történik, ha a gyorsítótár megtelt? Egy régebbi, nem használt linket lecserélhetünk egy újabb vagy népszerű URL-re. Választhatjuk a rendszerünk számára a Least Recently Used (LRU) cache kilakoltatási politikát. Ebben a politikában először a legkevésbé használt URL-t távolítjuk el.

★ Terheléselosztó:

Rendszerünk különböző helyein, az URL-rövidítő szerver, az adatbázis és a gyorsítótár szerverek előtt teherelosztó réteget adhatunk hozzá.

Egy egyszerű Round Robin megközelítést használhatunk a kérések elosztására. Ebben a megközelítésben az LB a bejövő kéréseket egyenlően osztja el a backend-kiszolgálók között. Az LB ezen megközelítése egyszerűen megvalósítható. Ha egy szerver halott, az LB nem küld több forgalmat hozzá.

Probléma: Ha egy szerver túlterhelt, az LB ebben a megközelítésben nem állítja le az új kérés küldését az adott szerverhez. Később szükségünk lehet egy intelligens LB-re.

★ Link lejárata egy időtartam után:

Ha egy URL elérte a lejárati időt, mi történik a linkkel?

Az adattárakban kereshetünk és eltávolíthatjuk őket. A probléma itt az, hogy ha úgy döntenénk, hogy a lejárt linkeket keressük, hogy eltávolítsuk őket az adattárunkból, az nagy nyomást gyakorolna az adatbázisunkra.

Megoldhatjuk máshogy is. Lassan, időszakosan eltávolíthatjuk a lejárt linkeket. Még ha néhány halott link tovább él is, azt soha nem szabad visszaadni a felhasználóknak.

Ha egy felhasználó megpróbál hozzáférni egy lejárt linkhez, eltávolíthatjuk a linket, és hibajelzést küldhetünk a felhasználónak. Rendszeres tisztítási folyamatot futtathatunk, hogy eltávolítsuk a lejárt linkeket az adatbázisunkból. Mivel a tárolás egyre olcsóbbá válik, néhány link akkor is ott maradhat, ha a tisztítás közben elmulasztjuk.

A link eltávolítása után visszatehetjük az adatbázisunkba, hogy újra felhasználhassuk.

★ Biztonság:

Tárolhatjuk a hozzáférés típusát (nyilvános/magán) minden URL-hez az adatbázisban. Ha egy felhasználó olyan URL-t próbál elérni, amelyhez nincs jogosultsága, a rendszer hibajelzést (HTTP 401) küldhet vissza.