Projete um encurtador de URL

Requisitos. Funcionais: criar um link curto para uma URL longa; redirecionar um link curto para a URL original; opcionalmente, aliases personalizados e expiração. Não funcionais: os redirecionamentos precisam ser rápidos e altamente disponíveis; o sistema tem muitíssima leitura (cada link é criado uma vez, mas clicado muitas vezes); os códigos não devem ser fáceis de adivinhar. Estimativas: 100 milhões de links novos por mês dão ~40 escritas por segundo; com 100:1, são ~4.000 redirecionamentos por segundo. Com ~500 bytes por link, cinco anos dão 100M × 60 meses × 500 B ≈ 3 TB.

• API: POST /links {longUrl} retorna {code}; GET /{code} responde com um redirecionamento.
• Espaço de códigos: base62 (0-9, a-z, A-Z) com 7 caracteres dá 62^7 ≈ 3,5 trilhões de códigos - mais que suficiente.
• Gerando códigos: (1) calcular o hash da URL longa e pegar 7 caracteres, verificando colisões; ou (2) pegar um ID inteiro único e codificá-lo em base62. Para evitar um contador único, cada servidor de aplicação reserva um bloco de IDs (digamos, 1.000 por vez) com um coordenador.
• Armazenamento: uma busca chave-valor code → {longUrl, createdAt, expiresAt, ownerId} combina com um banco chave-valor ou de colunas largas, ou com uma tabela relacional com sharding. Os códigos mais acessados ficam em cache.

Base62 funciona como qualquer outra base: 125 é 2 × 62 + 1, então vira 21. Sete caracteres dão 62^7, ou cerca de 3,5 trilhões de códigos.

Redirecionamentos: um 301 (permanente) deixa os navegadores guardarem o redirecionamento em cache, o que reduz a carga, mas esconde os cliques repetidos das métricas. Um 302 (temporário) faz cada clique passar pelo serviço, o que permite medir. Aprofundamentos de que os entrevistadores gostam: tratar colisões de hash, impedir a enumeração de códigos sequenciais, bloquear URLs maliciosas, expirar links e registrar as métricas de cliques de forma assíncrona por uma fila, para os redirecionamentos continuarem rápidos.