Quando precisarmos de uma nova chave, podemos pegar uma das IDs já geradas. Essa abordagem pode tornar as coisas mais rápidas, pois enquanto um novo pedido chega, não precisamos criar um ID, garantir sua singularidade, etc. UGS irá garantir que todos os IDs são únicos, e podem ser armazenados em um banco de dados para que os IDs não precisem ser gerados toda vez.

Como precisamos de um byte para armazenar um caractere, podemos armazenar todas essas chaves em:

6 (caracteres) * 68.7B (chaves únicas) ~= 412 GB.

★Availability & Confiabilidade:

Se guardarmos uma cópia do UGS, é um único ponto de falha. Então, precisamos de fazer uma réplica do UGS. Se o servidor primário morrer, o secundário pode tratar dos pedidos dos utilizadores.

Cada servidor UGS pode guardar em cache algumas chaves da chave-DB. Ele pode acelerar as coisas. Mas, temos de ter cuidado; se um servidor morre antes de consumir todas as chaves, vamos perder essas chaves. Mas, podemos assumir, isto é aceitável já que temos quase 68B chaves únicas de seis letras.

Para assegurar a disponibilidade, precisamos de assegurar a remoção de um único ponto de falha no sistema. A replicação para dados removerá um único ponto de falha e fornecerá backup. Nós podemos manter múltiplas replicações para garantir a confiabilidade do servidor de banco de dados. E também, para um serviço ininterrupto, outros servidores também precisam de cópias.

★DataStorage:

Neste sistema, precisamos armazenar bilhões de registros. Cada objecto que guardamos é possivelmente inferior a 1 KB. Um dado URL não está relacionado com outro. Portanto, podemos usar um banco de dados NoSQL como Cassandra, DynamoDB, etc. Uma escolha NoSQL seria mais fácil de escalar, o que é um dos nossos requisitos.

★ Escalabilidade:

Para suportar bilhões de URLs, precisamos particionar nossa base de dados para dividir e armazenar nossos dados em diferentes servidores DB.

i) Podemos particionar a base de dados com base na primeira letra da chave hash. Nós podemos colocar chaves começando com ‘A’ em um servidor, ‘B’ em outro servidor. Isto é chamado de Particionamento Baseado em Alcance.

O problema com esta abordagem é que ela pode levar a um particionamento desequilibrado. Por exemplo, há muito poucas palavras começando com ‘Z’. Por outro lado; podemos ter muitas URLs que começam com a letra ‘E.’

Podemos combinar letras que ocorrem menos frequentemente numa partição de base de dados.

ii) Também podemos particionar com base no hash dos objectos que estamos a armazenar. Podemos tomar o hash da chave para determinar a partição na qual podemos armazenar o objeto de dados. A função hash irá gerar um número de servidor, e nós iremos armazenar a chave nesse servidor. Este processo pode tornar a distribuição mais aleatória. Isto é Particionamento Baseado em Hash.

Se esta abordagem ainda levar a partições sobrecarregadas, precisamos usar Hashing Consistente.

★ Cache:

Podemos armazenar em cache URLs que são freqüentemente acessadas pelos usuários. Os servidores UGS, antes de fazer uma consulta ao banco de dados, podem verificar se o cache tem o URL desejado. Então não é necessário fazer a consulta novamente.

O que acontecerá quando o cache estiver cheio? Podemos substituir um link antigo não usado por um URL mais recente ou popular. Podemos escolher a política de despejo de cache menos usado recentemente (LRU) para o nosso sistema. Nesta política, removemos primeiro a URL menos recentemente utilizada.

★ Balanceador de carga:

Podemos adicionar uma camada de balanceamento de carga em diferentes locais do nosso sistema, em frente ao servidor de encurtamento de URL, banco de dados e servidores de cache.

Podemos usar uma simples abordagem Round Robin para distribuição de pedidos. Nesta abordagem, LB distribui pedidos de entrada igualmente entre servidores backend. Esta abordagem de LB é simples de implementar. Se um servidor estiver morto, LB irá parar de enviar qualquer tráfego para ele.

Problema: Se um servidor estiver sobrecarregado, LB não irá parar de enviar uma nova requisição para aquele servidor nesta abordagem. Podemos precisar de um LB inteligente mais tarde.

★ Expiração do link após uma duração:

Se o tempo de expiração for atingido para uma URL, o que aconteceria com o link?

Podemos pesquisar em nossos datastores e removê-los. O problema aqui é que se escolhêssemos procurar por links expirados para removê-los do nosso armazenamento de dados, isso colocaria muita pressão na nossa base de dados.

Podemos fazer isso de outra forma. Podemos remover links expirados periodicamente, lentamente. Mesmo que alguns links expirados vivam mais tempo, nunca devem ser devolvidos aos usuários.

Se um usuário tentar acessar um link expirado, podemos remover o link e retornar um erro para o usuário. Um processo de limpeza periódico pode ser executado para remover links expirados da nossa base de dados. Como o armazenamento está ficando mais barato, alguns links podem ficar lá mesmo se perdermos enquanto limpamos.

Após remover o link, podemos colocá-lo de volta em nosso banco de dados para reutilização.

★ Segurança:

Podemos armazenar o tipo de acesso (público/privado) com cada URL no banco de dados. Se um usuário tentar acessar uma URL, que ele não tem permissão, o sistema pode enviar um erro (HTTP 401) de volta.