Design de Encurtador de URL

O problema

Encurtador de URL parece simples demais para render boa entrevista.

E esse e justamente o valor dele.

Recebe uma URL longa, devolve uma curta, faz redirect depois.

Ele nao e o cenario mais rico do mundo.

Mas exige uma habilidade que entrevista adora medir:

saber localizar onde esta a parte realmente dificil.

No encurtador, a parte dificil geralmente nao e criar o link.

E servir redirect rapido em escala, sem transformar cada clique em ida cara ao banco.

Modelo mental

Esse sistema tem duas operações principais:

1. encurtar
2. redirecionar

Encurtar é escrita.

Redirecionar é leitura.

Na maioria dos cenarios, leitura domina muito mais do que escrita.

Isso muda a arquitetura inteira.

Se quiser resumir:

O caminho quente do encurtador costuma ser o GET /:shortId, não o POST /urls.

Quebrando o problema

Alinhe requisitos cedo

Antes de abrir o desenho, confirme:

• link expira ou não
• URL customizada existe ou não
• analytics em tempo real é obrigatório ou não
• redirect precisa ser muito rápido

Essas respostas mudam bastante o desenho.

Escolha a estratégia de shortId

Existem algumas opções clássicas:

• contador sequencial + codificação curta
• identificador aleatório
• hash da URL longa com tratamento de colisão

Cada uma troca uma dor por outra.

Contador simplifica unicidade, mas pode expor previsibilidade.

Aleatório reduz previsibilidade, mas pede controle de colisão.

Se o produto aceitar alias customizado, entra outra preocupação: reserva de nome, conflito e abuso.

Concretize lookup e persistência

O banco principal precisa guardar pelo menos:

• shortId
• URL longa
• metadata básica

O acesso dominante no caminho quente é por shortId.

Então esse lookup precisa ser direto e barato.

Proteja o redirect com cache

Como o caminho de leitura domina, cache faz muito sentido.

Se um link fica popular, cachear shortId -> longUrl evita bater no banco a cada clique.

Tire analytics do meio

Contar clique e importante.

Atrasar redirect por causa disso e erro.

O desenho saudável costuma ser:

• redireciona rápido
• registra evento de clique fora do caminho principal

Se o evento se perder de vez em quando, isso costuma ser aceitável.

Se o redirect falhar, não.

Exemplo simples

Uma resposta madura pode soar assim:

Vou assumir que o requisito principal é redirecionar muito rápido e que analytics detalhado pode ser assíncrono. A operação de encurtar é bem menos frequente do que a de redirecionar, então a arquitetura vai girar em torno do caminho de leitura. Para criar o link, posso gerar um identificador único, codificar em Base62, guardar o mapeamento no banco e devolver a URL curta. Para o redirect, vou buscar por shortId e usar cache para os links mais acessados. O clique pode virar evento fora do request principal.

Essa resposta já cobre:

• proporção de leitura e escrita
• geração de ID
• lookup por chave
• cache
• analytics assíncrono

Erros comuns

• Focar demais na criação e esquecer o caminho do redirect.
• Escolher ID sem falar de colisão ou previsibilidade.
• Colocar analytics no caminho síncrono.
• Ignorar expiração e customização quando o enunciado pede.
• Tratar cache como opcional sem olhar a proporção de leitura.

Como um senior pensa

Quem tem mais experiência costuma localizar cedo o fluxo dominante:

Eu quero criar link de forma simples, mas o sistema vive ou morre no redirect. Então eu desenho a leitura primeiro.

Esse tipo de prioridade deixa a resposta muito mais forte.

Porque mostra que você sabe onde realmente está o custo do sistema.

Num cenário desses, confundir telemetria com caminho crítico é um erro bem comum de gente que ainda não separa requisito principal de requisito importante.

O que o entrevistador quer ver

Nesse cenário, o entrevistador mede se você:

• separa criar de redirecionar
• percebe que leitura domina escrita
• pensa em identificador curto com critério
• protege o caminho quente com cache e tira analytics do meio

Encurtador de URL parece pequeno. Por isso mesmo ele mostra com clareza se voce sabe localizar o centro real da arquitetura.

Quando voce identifica o caminho quente cedo, o resto do desenho para de parecer chute.