Design de Sistema de Encurtador de URLs: Como Encurtadores de Links Funcionam Internamente

"Design de um encurtador de URLs" é uma das perguntas mais populares de entrevistas de design de sistemas — e com razão. Ela toca em hashing, bancos de dados, cache, balanceamento de carga e sistemas distribuídos, tudo em um produto aparentemente simples.

Neste guia, vamos explorar como os encurtadores de URLs realmente funcionam, as principais decisões de design e os trade-offs envolvidos em escala.

Um encurtador de URLs faz duas coisas:

1. 1Encurtar: Pegar uma URL longa e gerar um código curto
2. 2Redirecionar: Quando alguém visita a URL curta, redirecioná-lo para a original

Aqui está o fluxo de alto nível:

Usuário cria link curto:
  URL Longa → Gerar código curto → Armazenar mapeamento → Retornar URL curta

Usuário clica no link curto:
  URL Curta → Procurar código → Encontrar URL longa → Redirecionamento 301

O desafio central é gerar códigos únicos e curtos. Existem várias abordagens:

Converter um ID auto-incrementado para uma string Base62 usando caracteres [a-zA-Z0-9]:

• ID 1 → 1
• ID 62 → 10
• ID 238,328 → ZZZ

Um código Base62 de 7 caracteres suporta 62^7 = 3,5 trilhões de URLs únicas.

Vantagens: Simples, comprimento previsível, sem colisões Desvantagens: IDs sequenciais são previsíveis (usuários podem adivinhar outras URLs curtas)

Aplicar uma função de hash (MD5, SHA-256) à URL longa e pegar os primeiros N caracteres:

SHA256("https://example.com/very/long/url") → "a3f2b8c1..." Código curto: "a3f2b8c"

Vantagens: A mesma entrada sempre produz a mesma saída (deduplicação) Desvantagens: Colisões de hash requerem tratamento; comprimento de hash fixo pode desperdiçar espaço

Gerar uma string alfanumérica aleatória e verificar exclusividade:

Vantagens: Simples, imprevisível Desvantagens: Requer verificação de colisão a cada criação; fica mais lento conforme o banco de dados enche

A maioria dos sistemas em produção usa codificação Base62 com um gerador de ID distribuído. É simples, livre de colisões e performático. Na Linkly, usamos uma abordagem similar — você pode ler mais sobre como encurtadores de URLs funcionam para uma visão menos técnica.

A tabela central é direta:

urls ├── id (chave primária, auto-incrementado) ├── short_code (índice único) ├── long_url (o destino) ├── created_at (timestamp) ├── user_id (quem criou) └── click_count (contador desnormalizado)

SQL (PostgreSQL, MySQL): Conformidade ACID, consistência forte, bom para escala moderada. A maioria dos encurtadores de URLs começa aqui.

NoSQL (DynamoDB, Cassandra): Melhor escalabilidade horizontal para bilhões de URLs. Consistência eventual é aceitável para este caso de uso.

Híbrido: SQL para mapeamentos de URL (precisa de consistência forte para redirecionamentos), NoSQL ou banco de dados de série temporal para análise de cliques (alto volume de escrita, consistência eventual é aceitável).

Quando um usuário clica em um link curto, o sistema deve:

1. 1Analisar o código curto da URL
2. 2Procurar a URL longa correspondente
3. 3Retornar uma resposta de redirecionamento HTTP

• 301 (Permanente): O navegador armazena o redirecionamento em cache. Menos requisições ao servidor, mas você perde visibilidade dos cliques repetidos.
• 302 (Temporário): O navegador verifica com o servidor toda vez. Mais requisições, mas melhor rastreamento de cliques.

A maioria dos encurtadores de URLs usa redirecionamentos 302 para precisão no rastreamento de cliques, e oferece 301 como opção para casos de uso de SEO. Veja nosso guia sobre redirecionamentos 301 para mais informações sobre essa distinção.

Redirecionamentos precisam ser rápidos — cada milissegundo de latência afeta a experiência do usuário. Cache é crítico:

Armazenar o mapeamento código_curto → URL_longa em memória:

GET /abc123 → Verificar Redis por "abc123" → Cache hit? Retornar redirecionamento imediatamente → Cache miss? Consultar banco de dados, cachear resultado, retornar redirecionamento

Uma pequena instância Redis pode armazenar em cache milhões de mapeamentos de URL. Como a maioria do tráfego vai para um número relativamente pequeno de links populares, taxas de acerto de cache acima de 90% são comuns.

Para redirecionamentos 301, nós de borda da CDN podem cachear a resposta de redirecionamento, servindo-a da localização mais próxima do usuário sem sequer acessar seu servidor de origem.

Registrar dados de cliques é uma operação pesada em escrita que não deve desacelerar o redirecionamento:

1. 1Usuário clica no link curto
2. 2Sistema imediatamente retorna o redirecionamento
3. 3Evento de clique é enviado para uma fila de mensagens (Kafka, RabbitMQ, SQS)
4. 4Um worker em background processa o evento: analisa user agent, geolocaliza IP, armazena análise

Isso desacopla o caminho rápido de redirecionamento do pipeline de análise mais lento.

• Timestamp
• Endereço IP (para geolocalização)
• User agent (para detecção de dispositivo/navegador)
• Cabeçalho de referência
• País, cidade (de geolocalização de IP)

Encurtadores de URLs são extremamente pesados em leitura. Uma proporção típica pode ser 100:1 leituras para escritas. Isso significa:

• Otimizar o caminho de redirecionamento acima de tudo
• Usar cache agressivamente
• Réplicas de leitura para o banco de dados

Se usar IDs auto-incrementados em múltiplos servidores, você precisa evitar colisões. Opções:

• IDs Snowflake: Abordagem do Twitter — embute timestamp, ID de máquina e número de sequência
• UUID: Universalmente único mas mais longo
• Intervalos de ID: Atribua a cada servidor um intervalo de IDs para alocar

Implante servidores de redirecionamento em múltiplas regiões. Um usuário em Tóquio não deveria precisar fazer uma viagem de ida e volta para um servidor na Virgínia para um redirecionamento.

Encurtadores de URLs podem ser abusados para phishing e distribuição de malware. Sistemas em produção precisam:

• Verificação de URL — verificar destinos contra bancos de dados de malware e phishing
• Limitação de taxa — prevenir criação em massa de links curtos maliciosos
• Relatório de abuso — permitir que usuários reportem links suspeitos
• Páginas de visualização prévia — opcionalmente mostrar aos usuários para onde um link vai antes de redirecionar

Saiba mais sobre segurança de links e proteção contra fraude de cliques.

Além do encurtamento e redirecionamento básico, encurtadores de URLs em produção adicionam:

• Domínios personalizados — links curtos com marca usando seu próprio domínio
• Slugs personalizados — escolha seu próprio código curto em vez de caracteres aleatórios
• Expiração — links com limite de tempo que param de funcionar após uma data
• Proteção por senha — exigir uma senha para acessar o destino
• Testes A/B — rotacionar entre múltiplos destinos
• Segmentação geográfica — redirecionar por país
• Segmentação por dispositivo — diferentes destinos para mobile vs. desktop
• Códigos QR — gerar códigos escaneáveis para qualquer link curto

O design de sistema de encurtador de URLs é um ótimo exercício porque começa simples mas revela camadas de complexidade: geração de código, design de banco de dados, cache, pipelines de análise e prevenção de abuso. Compreender esses fundamentos ajuda se você está se preparando para entrevistas ou construindo suas próprias ferramentas.

Quer usar um encurtador de URLs em produção sem construir um? Comece com Linkly — toda a arquitetura descrita acima, pronta para usar com domínios personalizados, análise e recursos avançados.