Projetar um serviço de encurtamento de URLs

Serviço de Encurtamento de URL — Design de Alto Nível REQUISITOS FUNCIONAIS Os usuários podem submeter uma URL longa e receber um código curto exclusivo (por exemplo, https://short.ly/aB3xYz). Visitar a URL curta redireciona o navegador para o destino original. Links curtos expiram opcionalmente após um TTL configurável. Os usuários podem opcionalmente solicitar um alias personalizado. Um contador básico de cliques é mantido por link. REQUISITOS NÃO FUNCIONAIS O sistema deve lidar com aproximadamente 20 milhões de gravações e 200 milhões de leituras por mês, o que se traduz em cerca de 8 gravações/segundo e 80 leituras/segundo em média, com picos várias vezes maiores. A latência de redirecionamento deve ser inferior a 50 ms no percentil 95. O serviço deve ser altamente disponível (meta de 99,9% de tempo de atividade). Códigos curtos devem ser globalmente únicos. O sistema deve ser escalável horizontalmente e tolerar falhas de nó único com elegância. PONTOS DE EXTREMIDADE DA API POST /api/links aceita um corpo JSON com os campos: longUrl (obrigatório), customAlias (opcional), ttlDays (opcional). Retorna uma resposta JSON contendo shortCode e shortUrl. Este é o caminho de gravação. GET /{shortCode} é o ponto de extremidade de redirecionamento. O servidor procura o código e responde com HTTP 301 (permanente) ou 302 (temporário, preferível para análise) para a URL original. GET /api/links/{shortCode} retorna metadados: URL original, hora de criação, expiração, contagem de cliques. DELETE /api/links/{shortCode} marca um link como excluído (exclusão lógica). MODELO DE DADOS Uma única tabela primária, links, contém os dados principais. Colunas chave: short_code (varchar, chave primária), long_url (text, não nulo), created_at (timestamp), expires_at (timestamp, anulável), is_deleted (booleano, padrão falso), click_count (inteiro, padrão 0), owner_id (varchar, anulável para links anônimos). Um índice em expires_at suporta varreduras eficientes de expiração. Se aliases personalizados forem suportados, short_code é simplesmente definido para o valor fornecido pelo usuário após uma verificação de exclusividade. GERAÇÃO DE CÓDIGO CURTO A abordagem padrão usa uma codificação base-62 (caracteres a-z, A-Z, 0-9) de um ID inteiro exclusivo. Um código base-62 de 7 caracteres fornece 62^7 ≈ 3,5 trilhões de códigos possíveis, excedendo em muito a demanda previsível. O ID inteiro é produzido por um gerador de ID distribuído, como um serviço estilo Snowflake ou uma sequência de banco de dados. Isso garante exclusividade sem sobrecarga de coordenação na camada de aplicação. Na gravação, a aplicação codifica o ID gerado para produzir o código curto e armazena ambos. Para aliases personalizados, a aplicação verifica a existência de uma linha com esse short_code antes da inserção; se ocupado, retorna um erro de conflito ao chamador. FLUXO DE LEITURA E GRAVAÇÃO Caminho de gravação: O cliente envia POST para o serviço de API. O serviço valida a URL (verificação básica de formato, verificação opcional de lista de bloqueio). Ele obtém um novo ID exclusivo do gerador de ID, o codifica em um código curto e insere uma linha no banco de dados primário. O novo mapeamento é opcionalmente pré-carregado no cache. A URL curta é retornada ao cliente. Caminho de leitura: O cliente emite GET /{shortCode}. O serviço de API primeiro verifica o cache distribuído (Redis). Em um acerto de cache, ele retorna o redirecionamento 302 imediatamente e incrementa assincronamente o contador de cliques. Em uma falha de cache, ele consulta o banco de dados primário, grava o resultado no cache com um TTL (por exemplo, 24 horas) e, em seguida, redireciona. Se o código não for encontrado, expirado ou excluído, ele retorna 404. ARMAZENAMENTO E CACHE O armazenamento primário é um banco de dados relacional (PostgreSQL ou MySQL) por sua forte consistência, garantias ACID e imposição simples de chaves exclusivas. Com 20 milhões de links por mês e um tamanho de linha modesto (~500 bytes), um ano de dados é de aproximadamente 120 GB — facilmente gerenciável em um primário único com réplicas de leitura. Um cache distribuído em memória (Redis) fica na frente do banco de dados para o caminho de leitura. Dado que uma pequena fração de links representa a maior parte do tráfego (distribuição de lei de potência), um cache com política de remoção LRU e um TTL de 24 horas alcançará uma alta taxa de acertos com memória modesta. Estimando 10 milhões de links quentes a ~200 bytes cada requer apenas cerca de 2 GB de memória de cache. As contagens de cliques são armazenadas em buffer no Redis (INCR) e descarregadas para o banco de dados periodicamente para evitar amplificação de gravação. ESCALANDO PARA TRÁFEGO DE LEITURA INTENSO A camada de API é sem estado e escala horizontalmente atrás de um balanceador de carga. Réplicas de leitura do banco de dados absorvem consultas de leitura que falham no cache. O cluster de cache (Redis Cluster) pode ser particionado por short_code. Uma CDN pode ser colocada na frente do ponto de extremidade de redirecionamento para os links mais populares, servindo a resposta 302 dos nós de borda sem atingir a origem. Como as respostas 302 não são cacheadas pelos navegadores por padrão, a CDN deve ser configurada para cacheá-las por um curto período (por exemplo, 60 segundos) para ser eficaz. TRATAMENTO DE LINKS EXPIRADOS OU EXCLUÍDOS A expiração é verificada no momento da leitura: se expires_at estiver no passado ou is_deleted for verdadeiro, o serviço retorna 404 e remove a entrada do cache. Um trabalho em segundo plano é executado periodicamente (por exemplo, diariamente) para excluir permanentemente ou arquivar linhas onde expires_at passou, mantendo o conjunto de dados ativo pequeno e as varreduras de índice rápidas. Exclusões lógicas (flag is_deleted) permitem trilhas de auditoria e recuperação potencial antes da remoção permanente. PREVENÇÃO DE ABUSOS E LIMITAÇÃO DE TAXA A limitação de taxa é aplicada na camada do gateway de API usando um balde de tokens ou algoritmo de janela deslizante com chave no endereço IP e, para usuários autenticados, no ID do usuário. Padrões razoáveis: 10 gravações por minuto por IP para usuários anônimos, limites mais altos para contas autenticadas. No caminho de gravação, as URLs submetidas são verificadas em relação a uma lista de bloqueio de domínios conhecidos maliciosos ou de phishing (mantida como um conjunto Redis ou uma pequena trie em memória). CAPTCHA ou verificação por e-mail podem ser exigidos para padrões de submissão em massa ou suspeitos. Códigos curtos que recebem um pico incomum de respostas 404 (por exemplo, ataques de enumeração) podem acionar bloqueios de IP temporários. CONFIABILIDADE E GARGALOS O banco de dados primário é o ponto único de falha mais crítico. Mitigação: replicação síncrona para pelo menos um standby com failover automático (por exemplo, usando uma ferramenta como Patroni). A camada de cache melhora a disponibilidade servindo leituras mesmo durante a degradação breve do banco de dados. O gerador de ID deve ser altamente disponível; um gerador estilo Snowflake incorporado em cada nó de API (usando ID do nó + timestamp + sequência) elimina isso como uma dependência separada. Gargalos prováveis: o caminho de gravação do banco de dados durante picos de tráfego (mitigado por pool de conexões e agrupamento de gravações onde possível) e a remoção de cache sob um surto repentino de códigos curtos exclusivos (mitigado por pré-carregamento de links populares e ajuste do tamanho do cache). COMPROMISSOS E SUPOSIÇÕES Usar redirecionamentos 302 (temporários) em vez de 301 (permanentes) significa que os navegadores não armazenam o redirecionamento em cache, então cada visita atinge o serviço. Isso é intencional: permite a contagem precisa de cliques e permite que os links sejam atualizados ou excluídos. O compromisso é uma latência e carga ligeiramente maiores em comparação com 301. A codificação base-62 de um ID sequencial vaza a ordem aproximada de criação; se isso for uma preocupação, o ID pode ser hasheado ou um código aleatório pode ser gerado com uma verificação de exclusividade (tentar novamente em colisão). O design assume que a criação de links anônimos é permitida; adicionar autenticação melhoraria o controle de abusos, mas reduz a acessibilidade. As contagens de cliques usam consistência eventual (armazenadas em buffer no Redis, descarregadas assincronamente) em vez de incrementos transacionais estritos, aceitando imprecisões menores em troca de uma carga de gravação muito menor no banco de dados. Aliases personalizados são suportados, mas tratados como um caso de uso minoritário; eles não afetam o pipeline de geração principal.

## Projeto de Serviço de Encurtamento de URL Este documento descreve um projeto de alto nível para um serviço público de encurtamento de URL. ### Requisitos Funcionais Principais: 1. **Encurtar URL**: Os usuários podem enviar uma URL longa e receber um código curto exclusivo. 2. **Redirecionar**: Visitantes que acessam uma URL curta são redirecionados para a URL longa original. 3. **Apelidos Personalizados (Opcional)**: Os usuários podem opcionalmente especificar um apelido personalizado para seu código curto. ### Principais Requisitos Não Funcionais: 1. **Alta Disponibilidade**: O serviço deve estar disponível com tempo de inatividade mínimo. 2. **Baixa Latência**: Tanto o encurtamento quanto o redirecionamento devem ser rápidos. 3. **Escalabilidade**: O sistema deve lidar com um grande e crescente número de solicitações (20 milhões de novos links/mês, 200 milhões de redirecionamentos/mês). 4. **Durabilidade**: URLs curtas e seus mapeamentos não devem ser perdidos. 5. **Consistência**: Embora a consistência forte para escritas seja ideal, a consistência eventual pode ser aceitável para leituras em alguns cenários. ### Principais Pontos de Extremidade da API: * **POST /shorten** * **Corpo da Solicitação**: `{"url": "<url_longa>", "alias": "<apelido_personalizado_opcional>"}` * **Corpo da Resposta**: `{"short_code": "<codigo_curto>", "short_url": "<url_curta>"}` * **Descrição**: Cria uma nova URL curta. Se um apelido for fornecido e estiver disponível, ele será usado; caso contrário, um código curto exclusivo será gerado. * **GET /{short_code}** * **Resposta**: HTTP 301 (Redirecionamento Permanente) ou 302 (Redirecionamento Temporário) para a URL original. * **Descrição**: Redireciona o usuário para a URL longa original associada ao `short_code`. * **DELETE /{short_code}** (Opcional, para gerenciamento) * **Descrição**: Exclui um mapeamento de URL curta. ### Modelo de Dados: Podemos usar um banco de dados NoSQL como Cassandra ou DynamoDB por sua escalabilidade e disponibilidade. O esquema seria: * **Tabela: `urls`** * `short_code` (Chave Primária, String) * `long_url` (String) * `created_at` (Timestamp) * `user_id` (String, opcional, para rastrear a propriedade) * `is_active` (Booleano, para lidar com exclusões) * `alias` (String, opcional, indexado se usado para consulta) ### Geração e Unicidade do Código Curto: Gerar códigos curtos exclusivos é crucial. Várias abordagens: 1. **Codificação Base-62 de IDs Incrementais**: Um método comum e eficiente. Podemos usar um serviço de contador distribuído (por exemplo, Apache ZooKeeper ou um serviço personalizado construído com Redis ou um banco de dados) para gerar inteiros exclusivos e sempre crescentes de 64 bits. Esses inteiros são então codificados em uma string base-62 (0-9, a-z, A-Z). Isso garante a exclusividade e fornece códigos curtos de comprimento previsível (por exemplo, 7-8 caracteres para bilhões de IDs). 2. **Hashing**: Hashing da `long_url` (por exemplo, usando MD5 ou SHA-1) e pegando os primeiros caracteres. Colisões devem ser tratadas verificando entradas existentes. Se ocorrer uma colisão, anexe um sufixo exclusivo ou tente um hash diferente. Para este projeto, a **codificação Base-62 de IDs incrementais** é preferida por sua simplicidade em garantir exclusividade e comprimento previsível. Um serviço de geração de IDs distribuído será essencial. ### Fluxo de Solicitações de Leitura e Escrita: * **Solicitação de Escrita (Encurtar URL):** 1. O usuário envia uma solicitação POST para `/shorten` com uma `long_url` e apelido opcional. 2. O gateway da API roteia a solicitação para um **Serviço de Escrita**. 3. **Geração de Código Curto**: Se nenhum apelido for fornecido, o Serviço de Escrita solicita um ID exclusivo ao serviço de geração de IDs, que é então codificado em Base-62. 4. **Verificação de Apelido (se aplicável)**: Se um apelido for fornecido, verifique se ele já está em uso. Se estiver, retorne um erro. Caso contrário, use o apelido como `short_code`. 5. **Escrita no Banco de Dados**: Armazene o mapeamento (`short_code`, `long_url`, `created_at`, etc.) no banco de dados `urls`. Se o apelido for usado, uma entrada ou índice adicional pode ser necessário para consultas baseadas em apelido. 6. O Serviço de Escrita retorna o `short_code` e a `short_url` para o usuário. * **Solicitação de Leitura (Redirecionar):** 1. O usuário insere uma `short_url` (por exemplo, `short.domain/abcd123`). 2. A solicitação atinge o gateway da API e é roteada para um **Serviço de Leitura** (ou Serviço de Redirecionamento). 3. **Verificação de Cache**: O Serviço de Leitura primeiro verifica um cache distribuído (por exemplo, Redis) para o mapeamento `short_code` para `long_url`. 4. **Consulta ao Banco de Dados**: Se não for encontrado no cache, o Serviço de Leitura consulta o banco de dados `urls` usando o `short_code`. 5. **Atualização do Cache**: Uma vez recuperado do banco de dados, o mapeamento é adicionado ao cache para solicitações subsequentes. 6. **Redirecionamento**: O Serviço de Leitura retorna um redirecionamento HTTP (301 ou 302) para o navegador do usuário com a `long_url` original. ### Escolhas de Armazenamento e Estratégia de Cache: * **Armazenamento Primário**: Um banco de dados NoSQL distribuído como **Cassandra** ou **DynamoDB**. Estes oferecem alta disponibilidade, tolerância a falhas e escalabilidade horizontal, adequados para a natureza com muitas leituras do serviço. * **Cache**: Um cache distribuído em memória como **Redis** ou **Memcached** é crucial para o tráfego com muitas leituras. Ele armazenará mapeamentos de `short_code` para `long_url` frequentemente acessados. Isso reduz drasticamente a carga do banco de dados e melhora a latência de redirecionamento. Um TTL (Time-To-Live) pode ser definido em entradas de cache, ou elas podem ser invalidadas em escritas (embora isso adicione complexidade). ### Abordagem de Escalabilidade para Tráfego de Leitura Pesado: 1. **Réplicas de Leitura**: Para bancos de dados relacionais, use réplicas de leitura. Para NoSQL, sua natureza distribuída lida inerentemente com a escalabilidade de leituras. 2. **Camada de Cache**: Um cache distribuído robusto é o principal mecanismo. Escalar horizontalmente Redis/Memcached. 3. **Serviços Sem Estado**: Garanta que o Serviço de Leitura e o Serviço de Escrita sejam sem estado. Isso permite escalabilidade horizontal fácil adicionando mais instâncias atrás de um balanceador de carga. 4. **Balanceamento de Carga**: Use um balanceador de carga robusto (por exemplo, AWS ELB, Nginx) para distribuir o tráfego entre as instâncias do serviço. 5. **CDN**: Para as partes estáticas da interface web (se houver) e potencialmente para servir redirecionamentos de locais de borda, uma Rede de Distribuição de Conteúdo (CDN) pode ser empregada. ### Lidando com Links Expirados ou Excluídos: * **Exclusão**: A flag `is_active` no banco de dados pode ser usada. Quando um link é excluído, atualize `is_active` para `false`. O Serviço de Leitura verificaria essa flag durante as consultas ao banco de dados. A entrada também pode ser removida do cache. * **Expiração**: Adicione um timestamp `expires_at` à tabela `urls`. O Serviço de Leitura verificaria esse timestamp. Um trabalho de background automatizado pode limpar periodicamente entradas expiradas do banco de dados. ### Prevenção Básica de Abuso e Limitação de Taxa: * **Limitação de Taxa**: Implemente limitação de taxa no gateway da API ou dentro do Serviço de Escrita. Isso pode ser baseado em endereço IP, ID de usuário (se autenticado) ou chaves de API. Algoritmos comuns incluem Token Bucket ou Leaky Bucket. * **Validação de URL**: Antes de encurtar, valide a `long_url` de entrada para evitar URLs obviamente maliciosas ou malformadas. * **Detecção de Conteúdo Abusivo**: Monitore URLs que apontam para sites de phishing, malware ou spam. Isso pode envolver a integração com listas negras de terceiros ou o uso de modelos de aprendizado de máquina. * **Restrições de Apelido Personalizado**: Limite o uso de apelidos personalizados a usuários registrados/verificados para evitar abuso. ### Considerações de Confiabilidade e Possíveis Gargalos: * **Possíveis Gargalos**: * **Serviço de Geração de IDs**: Se não projetado para alta taxa de transferência e disponibilidade, pode se tornar um gargalo para escritas. * **Banco de Dados**: Alto volume de escrita ou consultas de leitura complexas (por exemplo, consultas de apelido sem índice) podem sobrecarregar o banco de dados. * **Cache**: Misses de cache com volumes de leitura muito altos podem sobrecarregar o banco de dados. Políticas de evicção de cache e escalabilidade são críticas. * **Latência de Rede**: Entre serviços, especialmente entre zonas de disponibilidade. * **Confiabilidade**: * **Redundância**: Implante serviços e bancos de dados em múltiplas zonas de disponibilidade. * **Failover**: Implemente failover automático para componentes críticos. * **Monitoramento e Alertas**: Monitoramento abrangente da saúde do sistema, métricas de desempenho e taxas de erro, com alertas para anomalias. * **Degradação Graciosa**: Se o cache falhar, o sistema ainda deve funcionar (embora mais lentamente) lendo diretamente do banco de dados. ### Trade-offs e Suposições: * **Suposições**: * Temos um mecanismo confiável para gerar IDs exclusivos e sequenciais em um ambiente distribuído. * A maioria das solicitações são leituras (redirecionamentos), justificando um investimento pesado em cache e escalabilidade de leitura. * Consistência forte para criação de links é desejável, mas consistência eventual para consultas de redirecionamento após um pequeno atraso de propagação é aceitável. * **Trade-offs**: * **Cache vs. Consistência**: Uma estratégia de cache altamente agressiva pode levar a dados desatualizados por um curto período após uma escrita, exigindo invalidação cuidadosa do cache ou gerenciamento de TTL. * **Complexidade de Geração de IDs**: Usar IDs incrementais é simples para exclusividade, mas requer um serviço de geração de IDs dedicado e altamente disponível. Hashing é mais simples de implementar inicialmente, mas requer tratamento robusto de colisões. * **Apelidos Personalizados**: O suporte a apelidos personalizados adiciona complexidade ao modelo de dados (índices secundários, resolução de conflitos) e ao caminho de escrita. * **Redirecionamentos Duráveis vs. Temporários**: Usar HTTP 301 (Permanente) assume que a URL curta sempre mapeará para a mesma URL longa. Usar 302 (Temporário) é mais flexível se os mapeamentos puderem mudar, mas pode ter implicações de SEO ou comportamentos de cache do navegador. Este projeto fornece uma base escalável, confiável e de alto desempenho para um serviço de encurtamento de URL.