Passo a passo de um encurtador de URLs: geração de chaves, status de redirecionamento e controles contra abuso

Objetivo

Transformar uma URL longa em uma chave curta que redirecione de forma confiável, possa ser desativada e não se torne um relay aberto para abuso.

Pré-requisitos

Uma decisão sobre quem pode criar links (usuários autenticados ou anônimos com limites) e sobre se o destino pode mudar depois da criação.

Passos

1. Restrições: os redirecionamentos devem continuar rápidos e disponíveis mesmo quando a criação estiver fora do ar; as chaves devem ser curtas, mas não enumeráveis em massa; todo link deve poder ser revogado. Decida se os cliques serão contados.
2. Componentes: uma API de criação; um armazenamento de chaves; um handler de redirecionamento atrás de um cache; uma verificação de abuso na criação (esquema restrito a http e https, destino que resolve para um endereço público, consulta a uma lista de bloqueio); um caminho administrativo que desativa uma chave e limpa o cache.
3. Modelo de dados: link(key, target, owner, created_at, expires_at, disabled_at), com índice primário em key e secundário em owner; opcionalmente click(key, at, referrer_class), gravado de forma assíncrona a partir do caminho de redirecionamento.
4. Geração de chaves: base62 aleatória de comprimento fixo, com nova tentativa em caso de colisão (sete caracteres dão 62^7, cerca de 3,5 trilhões de chaves); um contador codificado em base62 resulta em chaves mais curtas, mas permite que qualquer pessoa percorra todos os links. Aliases personalizados ficam em um namespace separado, com um conjunto de caracteres mais restrito e uma revisão contra falsificação de identidade.
5. Status de redirecionamento: a RFC 9110 define o 301 (Moved Permanently) como a indicação ao cliente de que as referências futuras devem usar o novo URI, enquanto o 302 (Found) indica que o cliente deve continuar usando o URI original. Um redirecionamento permanente pode, portanto, ser memorizado pelos clientes e contornar o serviço; por isso, use 302 ou 307 sempre que contagem ou revogação forem relevantes, e 301 apenas para links que nunca vão mudar. Adicione Cache-Control: no-store se os cliques forem contados.
6. Modos de falha: cache servindo um link desativado (invalidar ao desativar, com um TTL curto como reserva); queda do armazenamento (uma réplica de leitura ou um cache de borda servindo entradas desatualizadas); destinos de phishing (endpoint de denúncia, consulta de reputação, limites de criação por proprietário); loops para o próprio domínio do encurtador (rejeitar na criação); enumeração (chaves aleatórias, respostas 404 uniformes, limites de taxa nas consultas).
7. Métricas: latência de redirecionamento na cauda, taxa de acertos do cache, taxa de 404 como sinal de enumeração, criações por proprietário por hora, links desativados por dia, tempo entre a denúncia de abuso e a desativação.
8. Não construir primeiro: painéis de analytics, domínios personalizados, QR codes, prévias de links, destinos divididos, chaves de API para criação em lote.

Resultado esperado

Um redirecionamento passa por no máximo um cache e um armazenamento, um link pode ser desativado em segundos e o abuso é limitado por restrições na criação, e não por revisão manual.

Limites e base de verificação

Projeto proposto, sem medições. A escolha entre 301 e 302 é difícil de reverter depois que os clientes armazenam redirecionamentos permanentes em cache, por isso deve ser feita antes do lançamento.