Projetar um Serviço de Encurtamento de URLs

1) Requisitos Funcionais Núcleo (MVP) - Criar URL curta - Entrada: url_longa, alias_personalizado opcional, expiração opcional, user_id/api_key opcional - Saída: url_curta, chave, criado_em, expira_em - Redirecionar - GET /{chave} -> 301/302 para url_longa - Respeitar expiração/estado desabilitado - Análise básica - Contar redirecionamentos por chave (total + intervalos de tempo) - Opcional: referenciador, país/região (agregado), família de user-agent, tipo de dispositivo - Gerenciamento de links - Recuperar metadados (url_longa, criado_em, expira_em, status) - Desabilitar/excluir (exclusão lógica) Bom ter - Domínios personalizados por cliente - API de encurtamento em massa - Geração de código QR - Verificações anti-malware / navegação segura - Roteamento A/B, modelos UTM Não funcionais - Latência de redirecionamento muito baixa (p95 < ~20–50ms de edge/cache) - Alta disponibilidade (multi-AZ/região) - Consistência forte não é necessária para análise, mas é necessária para o mapeamento chave->URL 2) Arquitetura de Alto Nível Fluxo de tráfego - DNS -> CDN/Edge (opcional, mas recomendado) - Balanceador de carga global (GSLB) -> Balanceador de carga L7 regional - API Gateway - Autenticação (chaves de API/OAuth), limitação de taxa, validação de solicitação - Serviços de aplicativos (stateless) - Serviço de Encurtamento (escritas) - Serviço de Redirecionamento (leituras, caminho extremamente acessado) - Serviço de Ingestão de Análise (assíncrono) Camada de dados - Armazenamento primário Chave-Valor para mapeamento chave -> registro de destino - Camada de cache (Redis/Memcached) para consultas de chaves quentes - Pipeline de análise - Serviço de Redirecionamento emite evento para um log/fila (Kafka/PubSub/Kinesis) - Processador de fluxo agrega em um armazenamento OLAP (ClickHouse/BigQuery/Druid) e/ou de séries temporais (Cassandra/Scylla) - Agregações periódicas para dashboards Serviços de suporte - Serviço de geração de chaves (se estiver usando IDs pré-gerados) - Serviço de detecção de abuso (reputação de URL, comportamento do usuário) - Observabilidade: métricas, rastreamento, logs Interação - Criação: - Cliente -> API Gateway -> Serviço de Encurtamento - Validar URL, verificar abuso, unicidade opcional de alias personalizado - Obter chave única (estratégia de codificação abaixo) - Escrever mapeamento no DB - Invalidar/preencher cache - Redirecionamento: - Cliente -> CDN/Edge -> Serviço de Redirecionamento - Consultar chave no cache; em caso de falha, consultar DB - Se encontrado e não expirado/desabilitado: responder 301/302 - Emitir evento de análise assíncrono 3) Estratégia de Codificação de URL Objetivos: unicidade, comprimento curto, alto throughput, sem gargalo central. Recomendado: ID numérico + Base62 - Usar um ID de 64 bits monotonicamente crescente (ou ordenado por tempo) e codificar em Base62 (0-9a-zA-Z). - Para 100M de URLs novas/mês (~3,86k gravações/segundo em média; pico mais alto), a geração de ID deve suportar > dezenas de milhares/segundo. Opções: A) Sequência do banco de dados (simples) - Prós: fácil, fortemente único - Contras: pode ser gargalo e difícil entre shards; requer coordenação B) ID distribuído (semelhante a Snowflake) (recomendado) - 64 bits: timestamp + região/nó + sequência - Prós: escalável, sem gravador único - Contras: chaves ligeiramente mais longas se você codificar 64 bits completos; ainda compacto em Base62 (até 11 caracteres) C) Pool de chaves pré-geradas - Trabalho em segundo plano gera strings Base62 aleatórias, armazena pool não utilizado; o aplicativo reserva chaves. - Prós: desacopla da ordenação, pode manter chaves curtas - Contras: complexidade de gerenciamento de pool Tratamento de colisão - Para abordagem baseada em ID: sem colisões por construção. - Para aliases personalizados ou chaves aleatórias: impor unicidade com put condicional/restrição única; em caso de colisão, tentar novamente com nova chave. Comprimento da chave - Comprimento Base62 necessário: 100M/mês implica ~1,2B/ano. Base62^7 ≈ 3,5T, então 7 caracteres são suficientes se usar IDs sequenciais; IDs Snowflake podem ter 10–11 caracteres, mas são aceitáveis. 4) Design do Banco de Dados Requisitos do armazenamento primário - QPS de leitura muito alto, consultas baseadas em chave, registros pequenos, baixa latência. - Gravações fortemente consistentes para unicidade de chave; leituras podem ser eventualmente consistentes se o cache estiver correto, mas preferir leitura consistente após gravação para novos links. Recomendado: DynamoDB / Cassandra / ScyllaDB (NoSQL KV) OU MySQL/Postgres com sharding. - Prós NoSQL KV: escala horizontal, alto throughput, latência previsível. - Prós SQL: restrições, transações, mais simples para unicidade de alias personalizado e consultas administrativas; mas sharding/réplicas se tornam mais complexos em escala. Escolha pragmática - Armazenamento de mapeamento: DynamoDB (ou Cassandra/Scylla) como sistema de registro. - Armazenamento relacional opcional para usuário/conta/cobrança. Esquema principal (KV / wide-column) Tabela: url_mapping - chave (chave de partição, string) - url_longa (string) - criado_em (timestamp) - expira_em (timestamp, nulo) - status (ativo|desabilitado|excluído) - user_id (string/uuid, nulo) - alias_personalizado (booleano) - dominio (string, padrão) - ultimo_acesso_em (timestamp, nulo) - codigo_redirecionamento (int: 301/302) Índices / padrões de acesso - Primário: chave -> registro - Por usuário (para UI de gerenciamento): índice secundário - GSI: user_id como chave de partição, created_at como chave de ordenação (ou inversa) - Por url_longa (deduplicação opcional): índice hash(url_longa) (somente se você quiser o comportamento "mesma url_longa retorna mesma chave") Armazenamento de análise (separado) - Eventos brutos em armazenamento de objetos (S3/GCS) + agregação de streaming em OLAP. - Exemplo de tabela agregada (ClickHouse): (chave, dia/hora, redirecionamentos, ips_unicos_aprox, pais, dominio_referenciador, familia_ua) Resumo do trade-off SQL vs NoSQL - SQL: unicidade mais fácil para aliases personalizados, consultas ad-hoc; mais difícil de escalar gravações/leituras sem sharding cuidadoso. - NoSQL: melhor para carga de trabalho de consulta primária; deve projetar padrões de acesso antecipadamente; unicidade para aliases personalizados tratada via escritas condicionais. 5) Escalabilidade e Desempenho Estimativas de tráfego - Gravações: 100M/mês ≈ 3,86k/s em média, planejar para pico 10x => ~40k/s. - Leituras: 100:1 => 386k/s em média de redirecionamentos, planejar pico 10x => ~4M/s pico globalmente. Armazenamento - 100M/mês * 12 = 1,2B mapeamentos/ano. - Tamanho do registro (chave ~10B, URL avg 200B, metadados): assumir ~500B–1KB. - 1,2B * 1KB ≈ 1,2 TB/ano (mais replicação e índices). Cache - Cluster Redis/Memcached por região. - Chave de cache: chave curta; valor: url_longa + status + expira_em + codigo_redirecionamento. - Estratégia de TTL: - Para links sem expiração: TTL longo (ex: 1–7 dias) com atualização ao acesso. - Para links com expiração: TTL alinhado com a expiração. - Cache negativo para chaves ausentes/desabilitadas (TTL curto) para reduzir acessos ao DB. - Cache CDN/Edge para redirecionamentos onde for seguro: - Cache 301 para links públicos e sem expiração; cuidado com redirecionamentos por usuário ou dinâmicos. Sharding/particionamento - NoSQL: particionar por chave; garantir distribuição uniforme. - Se SQL: particionar por hash da chave; manter camada de roteamento. Réplicas de leitura - Se usar SQL ou um armazenamento KV replicado: adicionar réplicas de leitura para consultas de gerenciamento/leitura intensiva não de redirecionamento. Chaves quentes - URLs curtas extremamente populares podem sobrecarregar nós de cache. - Usar hashing consistente com nós virtuais suficientes. - Considerar cache LRU em memória no serviço de redirecionamento. - Cache de edge em CDN reduz a carga de origem. Otimização do caminho de gravação - Agrupar eventos de análise; nunca bloquear o redirecionamento na análise. 6) Confiabilidade e Disponibilidade Multi-AZ - Executar serviços de API/Redirecionamento em várias AZs atrás de um balanceador de carga. - Cache: cluster Redis com replicação + failover automático (ou Redis gerenciado). - DB: replicação multi-AZ; leituras/gravações de quorum conforme apropriado. Multi-região (recomendado para serviço global) - Redirecionamentos ativo-ativo: replicar DB de mapeamento entre regiões (tabelas globais DynamoDB / multi-DC Cassandra). - Gravações podem ser roteadas para a região mais próxima; resolver conflitos: - Para chaves baseadas em ID, colisões são improváveis; aliases personalizados exigem unicidade global — tratar roteando a criação de alias personalizado para uma "região de origem" por domínio ou usando coordenação global fortemente consistente (caminho raro). Failover - Verificações de integridade + mudança de tráfego automatizada via GSLB. - Serviços stateless permitem escalonamento e substituição rápidos. Backups e DR - Backups/snapshots contínuos do armazenamento de mapeamento. - Armazenar logs brutos de análise em armazenamento de objetos durável. Degradação graciosa - Se o pipeline de análise estiver inativo, continuar redirecionamentos e bufferizar eventos (retenção de fila) ou amostrar. - Se o cache estiver inativo, o serviço de redirecionamento volta para o DB (esperar aumento de latência, mas o serviço permanece funcional). 7) Limitação de Taxa e Prevenção de Abuso Limitação de taxa - Limites por chave de API/usuário/IP para endpoints de criação (token bucket/leaky bucket no API Gateway). - Limites separados e mais altos para redirecionamentos; proteger contra inundações com CDN/WAF. Controles de abuso - Validação de URL: permitir esquemas (http/https), comprimento máximo, bloquear faixas de IP internas (estilo SSRF) para componentes de visualização/verificação. - Detecção de malware/phishing: - Integrar com feeds de Navegação Segura/reputação. - Verificação assíncrona; opcionalmente estado "pendente" até que a verificação seja aprovada para usuários não confiáveis. - Políticas de alias personalizado: palavras reservadas, filtro de palavrões, políticas de marca registrada. - Detecção de bots: heurísticas de impressão digital de dispositivo, CAPTCHA para tráfego de criação suspeito. - Proteção de redirecionamento: - Regras de WAF, detecção de anomalias em padrões de redirecionamento. - Alertas de taxa de redirecionamento por chave; limitação temporária. Resumo do Planejamento de Capacidade/Throughput (aproximado) - Redirecionamentos de pico: almejar alguns milhões de solicitações/segundo globalmente. - Offload de CDN + caches regionais devem servir a maioria (almejar >95% de taxa de acerto para o conjunto quente). - Leituras do DB de origem devem ser minimizadas; projetar para <5% de falhas. - Gravações: dezenas de milhares/segundo no pico; geração de ID distribuída evita gargalo central. - Crescimento de dados: ~1,2B mapeamentos/ano; planejar armazenamento de vários TB com replicação e sobrecarga de indexação. Ponto de partida da implementação (lista de componentes) - API Gateway + Autenticação - Serviço de Encurtamento - Serviço de Redirecionamento (otimizado, dependências mínimas) - Cluster de cache Redis por região - DB de Mapeamento (DynamoDB/Cassandra/Scylla) - Gerador de ID (Snowflake) biblioteca/serviço - Kafka/Kinesis + processadores de fluxo + armazenamento OLAP - Serviço de Administração/gerenciamento + DB de usuário - Monitoramento/alertas + WAF/CDN

### 1. Requisitos Funcionais * **Funcionalidade Principal**: * **Encurtamento de URL**: Os usuários podem enviar um URL longo e receber um URL curto e exclusivo. * **Redirecionamento de URL**: O acesso a um URL curto redirecionará o usuário para o URL longo original com um redirecionamento 301 (permanente). * **Recursos Estendidos**: * **URLs Personalizados**: Os usuários podem escolher um alias personalizado para seu URL curto (por exemplo, `short.co/meu-evento`). * **Expiração de URL**: Os usuários podem definir um tempo/data de expiração para um URL curto, após o qual ele não redirecionará mais. * **Análises**: O serviço rastreará métricas básicas para cada link, como cliques totais, referenciadores e localização geográfica dos cliques. * **Acesso à API**: Uma API REST estará disponível para desenvolvedores integrarem o serviço de encurtamento em seus aplicativos. * **Contas de Usuário**: Usuários registrados podem gerenciar seus links, visualizar análises e acessar limites de taxa de API mais altos. ### 2. Arquitetura de Alto Nível O sistema foi projetado para ser altamente disponível e escalável, com uma clara separação dos caminhos de leitura e escrita. 1. **Balanceador de Carga (LB)**: Distribui o tráfego de entrada entre vários servidores web para evitar que um único servidor seja um gargalo. Ele lida com a terminação SSL. 2. **Servidores Web/API**: Uma frota de servidores sem estado executando a lógica da aplicação. Eles lidam com duas solicitações primárias: * `POST /api/v1/url` (Caminho de escrita): Cria um novo URL curto. * `GET /{short_key}` (Caminho de leitura): Redireciona para o URL longo. 3. **Serviço de Geração de Chaves (KGS)**: Um microsserviço dedicado responsável por gerar chaves curtas e exclusivas. Ele pré-gera chaves e as armazena em uma fila para garantir baixa latência para o caminho de escrita. 4. **Cache**: Um cache distribuído em memória (por exemplo, Redis Cluster) fica entre os servidores da aplicação e o banco de dados. Ele armazena mapeamentos de `short_key` para `long_url` para links acessados com frequência, a fim de servir redirecionamentos com latência muito baixa. 5. **Banco de Dados**: O armazenamento de dados principal para todos os mapeamentos de URL e dados do usuário. 6. **Pipeline de Análises**: Eventos de redirecionamento são publicados em uma fila de mensagens (por exemplo, Kafka). Um serviço separado consome esses eventos, agrega dados e os armazena em um data warehouse (por exemplo, ClickHouse ou AWS Redshift) para consultas de análise. **Fluxo de Interação (Redirecionamento)**: `Cliente` -> `Balanceador de Carga` -> `Servidor de API` -> `Cache (Redis)`. Se o cache for bem-sucedido, retorna o redirecionamento. Se o cache falhar, -> `Banco de Dados` -> `Servidor de API` -> `Cliente`. O mapeamento é então gravado no cache para solicitações subsequentes. ### 3. Estratégia de Codificação de URL Usaremos uma estratégia de **codificação Base62** combinada com um gerador de ID exclusivo. * **Abordagem**: O Serviço de Geração de Chaves (KGS) gerenciará um contador global de 64 bits (por exemplo, usando uma sequência dedicada de banco de dados SQL, Zookeeper ou um serviço personalizado). * **Processo**: 1. Quando um servidor de aplicação precisar criar um link, ele solicitará um ID exclusivo ao KGS. 2. O KGS fornece um número exclusivo (por exemplo, `10001`). 3. O servidor de aplicação converte este número em uma string Base62 (`[a-zA-Z0-9]`). Por exemplo, `10001` em Base62 é `2k1`. 4. Para garantir um comprimento fixo e evitar chaves curtas e adivinháveis, podemos usar um comprimento de 7 caracteres. Um contador de 64 bits fornece IDs exclusivos mais do que suficientes (2^64), que podem ser mapeados para uma string Base62. Uma string Base62 de 7 caracteres pode representar 62^7 (~3,5 trilhões) de URLs exclusivos, o que é suficiente para nossa escala. * **Tratamento de Colisão**: Esta abordagem garante exclusividade, portanto, colisões são impossíveis por design. Isso é superior à codificação do URL longo, que pode produzir colisões e requer verificações adicionais. ### 4. Design do Banco de Dados Dada a demanda de leitura massiva e os requisitos de escalabilidade, um **banco de dados NoSQL** como Apache Cassandra ou Amazon DynamoDB é a escolha ideal. * **Por que NoSQL?**: O padrão de acesso primário é uma simples pesquisa de chave-valor (`short_key` -> `long_url`). Bancos de dados NoSQL se destacam em escalonamento horizontal, alta disponibilidade e leituras de baixa latência para este padrão, o que é perfeito para nossa proporção de leitura para escrita de 100:1. * **Compensação SQL**: Um banco de dados SQL fragmentado (por exemplo, PostgreSQL com Citus) poderia funcionar, mas introduziria mais complexidade operacional para fragmentação e escalonamento neste nível. **Esquema da Tabela Principal (Cassandra/DynamoDB-like)**: * **Nome da Tabela**: `urls` * **Chave Primária**: `short_key` (Servirá como chave de partição, garantindo que os dados sejam distribuídos uniformemente pelo cluster). * **Colunas**: * `short_key` (texto, Chave de Partição) * `long_url` (texto) * `user_id` (uuid) * `created_at` (timestamp) * `expires_at` (timestamp) - Podemos definir um Tempo de Vida (TTL) na linha com base neste valor para limpeza automática. ### 5. Escalabilidade e Desempenho * **Estimativas de Capacidade**: * **Gravações**: 100 milhões de URLs/mês ≈ 40 gravações/seg (média). * **Leituras**: 10 bilhões de leituras/mês ≈ 3.850 leituras/seg (média). O tráfego de pico pode ser 10-20x este valor. * **Armazenamento**: 100 milhões de URLs/mês * 12 meses * 5 anos = 6 bilhões de URLs. Com aproximadamente 500 bytes por entrada, são ~3 TB de dados. * **Escalonando o Caminho de Leitura**: * **Cache**: Este é o componente mais crítico. Usaremos um cache de várias camadas. * **Cache CDN**: Usar uma CDN (por exemplo, Cloudflare) para armazenar em cache redirecionamentos na borda. Isso pode descarregar uma porcentagem significativa do tráfego para links populares. * **Cache Distribuído**: Um cache em memória como Redis será usado. Com 10 bilhões de leituras/mês, muitos URLs estarão 'quentes'. Armazenar em cache até mesmo 10-20% dos URLs mais ativos pode reduzir a carga de leitura do banco de dados em mais de 80-90%. * **Fragmentação de Banco de Dados**: Nossa escolha de NoSQL com `short_key` como chave de partição lida com isso naturalmente. Podemos adicionar mais nós ao cluster do banco de dados para escalar horizontalmente tanto o armazenamento quanto a taxa de transferência. ### 6. Confiabilidade e Disponibilidade * **Redundância**: Todos os componentes serão implantados em várias Zonas de Disponibilidade (AZs). * **Balanceadores de Carga, Servidores de API**: Implantados em um grupo de autoescalonamento em pelo menos duas AZs. * **Cache (Redis)**: Implantado em uma configuração de cluster com réplicas em diferentes AZs. * **Banco de Dados (Cassandra)**: O banco de dados será configurado com um fator de replicação de 3, com réplicas armazenadas em diferentes AZs para garantir durabilidade e disponibilidade dos dados durante uma falha de AZ. * **Failover**: Mecanismos de failover automatizados estarão em vigor. O balanceador de carga roteará automaticamente o tráfego para longe de instâncias não saudáveis. Serviços gerenciados de banco de dados geralmente lidam com failover de banco de dados automaticamente. * **Backup de Dados**: Capturas de tela regulares do banco de dados serão tiradas e armazenadas em uma região separada para recuperação de desastres. ### 7. Limitação de Taxa e Prevenção de Abuso * **Limitação de Taxa**: Implementada no Gateway de API ou na lógica da aplicação usando um armazenamento em memória como Redis. * Os limites serão baseados no endereço IP para usuários anônimos (por exemplo, 10 criações/minuto) e na chave de API para usuários registrados (com diferentes níveis). * **Prevenção de Abuso**: * **Verificação de URL Malicioso**: Integração com um serviço como a API Google Safe Browsing para verificar cada `long_url` enviado em relação a uma lista de bloqueio de sites maliciosos. * **CAPTCHA**: Para usuários anônimos exibindo padrões de envio de alta frequência. * **Lista de Bloqueio**: Manter uma lista de bloqueio interna de domínios e contas de usuário conhecidas por spam.