Când avem nevoie de o nouă cheie, putem lua unul dintre ID-urile deja generate. Această abordare poate face lucrurile mai rapide, deoarece, în timp ce vine o nouă cerere, nu trebuie să creăm un ID, să ne asigurăm de unicitatea acestuia etc. UGS se va asigura că toate ID-urile sunt unice, iar acestea pot fi stocate într-o bază de date, astfel încât ID-urile nu trebuie să fie generate de fiecare dată.

Cum avem nevoie de un octet pentru a stoca un caracter, putem stoca toate aceste chei în:

6 (caractere) * 68.7B (chei unice) ~= 412 GB.

★Disponibilitate & Fiabilitate:

Dacă păstrăm o singură copie a UGS, este un singur punct de eșec. Așadar, trebuie să facem o replică a UGS. Dacă serverul primar moare, cel secundar poate gestiona cererile utilizatorilor.

Care server UGS poate stoca în memoria cache anumite chei din key-DB. Aceasta poate accelera lucrurile. Dar, trebuie să fim atenți; dacă un server moare înainte de a consuma toate cheile, vom pierde acele chei. Dar, putem presupune că acest lucru este acceptabil din moment ce avem aproape 68B chei unice de șase litere.

Pentru a asigura disponibilitatea, trebuie să ne asigurăm că eliminăm un singur punct de eșec în sistem. Replicația pentru date va elimina un singur punct de eșec și va asigura o copie de rezervă. Putem păstra mai multe replicări pentru a asigura fiabilitatea serverului de baze de date. Și, de asemenea, pentru un serviciu neîntrerupt, și alte servere au nevoie de copii.

★Stocarea datelor:

În acest sistem, trebuie să stocăm miliarde de înregistrări. Fiecare obiect pe care îl păstrăm este posibil să fie mai mic de 1 KB. Datele unui URL nu sunt legate de altele. Prin urmare, putem utiliza o bază de date NoSQL, cum ar fi Cassandra, DynamoDB etc. O alegere NoSQL ar fi mai ușor de scalat, care este una dintre cerințele noastre.

★ Scalabilitate:

Pentru a susține miliarde de URL-uri, trebuie să partiționăm baza de date pentru a împărți și stoca datele noastre în diferite servere DB.

i) Putem partiționa baza de date pe baza primei litere a cheii hash. Putem pune cheile care încep cu „A” într-un server, „B” în alt server. Aceasta se numește partiționare bazată pe interval.

Problema cu această abordare este că poate duce la o partiționare dezechilibrată. De exemplu, există foarte puține cuvinte care încep cu ‘Z.’ Pe de altă parte; s-ar putea să avem prea multe URL-uri care încep cu litera ‘E.’

Am putea combina litere mai puțin frecvente într-o partiție a bazei de date.

ii) Putem, de asemenea, să facem partiții bazate pe hash-ul obiectelor pe care le stocăm. Putem lua hash-ul cheii pentru a determina partiția în care putem stoca obiectul de date. Funcția hash va genera un număr de server, iar noi vom stoca cheia în acel server. Acest proces poate face ca distribuția să fie mai aleatorie. Aceasta este Hash-Based Partitioning.

Dacă această abordare duce în continuare la partiții supraîncărcate, trebuie să folosim Consistent Hashing.

★ Cache:

Potem pune în cache URL-urile care sunt accesate frecvent de către utilizatori. Serverele UGS, înainte de a efectua o interogare a bazei de date, pot verifica dacă în memoria cache există URL-ul dorit. Atunci nu este nevoie să facă din nou interogarea.

Ce se va întâmpla când memoria cache este plină? Putem înlocui un link mai vechi nefolosit cu un URL mai nou sau popular. Putem alege politica de evacuare a cache-ului LRU (Least Recently Used) pentru sistemul nostru. În cadrul acestei politici, eliminăm mai întâi URL-ul cel mai puțin utilizat recent.

★ Echilibrator de sarcină:

Potem adăuga un strat de echilibrare a încărcăturii în diferite locuri din sistemul nostru, în fața serverului de scurtare a URL-urilor, a bazei de date și a serverelor de cache.

Potem folosi o abordare simplă Round Robin pentru distribuirea cererilor. În această abordare, LB distribuie cererile primite în mod egal între serverele backend. Această abordare a LB este simplu de implementat. Dacă un server este mort, LB va înceta să mai trimită orice trafic către acesta.

Problemă: Dacă un server este supraîncărcat, LB nu va înceta să trimită o nouă cerere către acel server în această abordare. S-ar putea să avem nevoie de un LB inteligent mai târziu.

★ Expirarea legăturii după o anumită durată:

Dacă se atinge timpul de expirare pentru un URL, ce se va întâmpla cu legătura?

Potem căuta în depozitele noastre de date și le putem elimina. Problema aici este că, dacă am alege să căutăm linkurile expirate pentru a le elimina din depozitul nostru de date, aceasta ar exercita o presiune mare asupra bazei noastre de date.

Potențiam face acest lucru într-un alt mod. Putem elimina încet și periodic link-urile expirate. Chiar dacă unele linkuri moarte trăiesc mai mult timp, nu ar trebui să fie niciodată returnate utilizatorilor.

Dacă un utilizator încearcă să acceseze un link expirat, putem să eliminăm link-ul și să returnăm o eroare utilizatorului. Un proces de curățare periodică poate rula pentru a elimina legăturile expirate din baza noastră de date. Deoarece spațiul de stocare este din ce în ce mai ieftin, unele linkuri ar putea rămâne acolo chiar dacă ratăm în timp ce facem curățarea.

După eliminarea linkului, îl putem pune înapoi în baza noastră de date pentru reutilizare.

★ Securitate:

Potem stoca tipul de acces (public/privat) cu fiecare URL din baza de date. Dacă un utilizator încearcă să acceseze un URL, pentru care nu are permisiune, sistemul poate trimite înapoi o eroare (HTTP 401).

.