Projete um Serviço de Encurtamento de URL em Escala

Arquitetura de alto nível (diagrama textual e componentes) - Clientes: navegadores web, aplicativos móveis. Eles acessam URLs curtas (short.example/abc1234) e a API de escrita para criação de URLs curtas. - CDN / Edge (CloudFront, Fastly): Camada de borda que recebe solicitações de URLs curtas de entrada. A borda armazenará em cache respostas de redirecionamento (HTTP 301/302) e as servirá sem tocar na origem, sempre que possível, para atender ao SLA de latência. - Roteamento de Borda / DNS Global (Route53, anycast): Roteia chamadas da API de escrita para a região mais próxima e acessos de URL curta para a borda/região mais próxima. Verificações de integridade e failover são configurados. - Gateway de API Regional + Balanceador de Carga (API Gateway / ALB): Aceita escritas de clientes e chamadas de gerenciamento. Roteia para Serviços de Escrita implantados em contêineres (ECS/Kubernetes) em zonas de disponibilidade. - Serviço de Escrita (microsserviço sem estado): Valida a entrada, gera um token curto através do módulo gerador de ID, grava o mapeamento no banco de dados primário, publica eventos no stream, atualiza caches e retorna a URL curta. - Serviços de Caminho de Leitura / Serviço de Redirecionamento (sem estado): Recebe falhas de cache da borda ou acessos diretos, consulta o cache local (cluster Redis), recorre ao banco de dados, retorna o redirecionamento com cabeçalhos de cache apropriados. - Cache Distribuído (clusters Redis por região, clusterizado/replicado): Consultas frequentes armazenadas aqui para respostas de microssegundos. Cada região tem seu próprio cluster Redis com replicação entre AZs. - Armazenamento Primário (DynamoDB ou alternativa Cassandra/Scylla): Armazena o mapeamento short_id -> long_url, metadados, expiração, proprietário, ts de criação. Escolhido por alta taxa de leitura/escrita, suporte a TTL e replicação multirregional. - Event Stream (Kinesis / Kafka): Todas as escritas produzem eventos para análise, atualizações de índice, mensagens de invalidação de cache e processamento assíncrono. - Workers de Background (em contêineres): Lidam com limpeza de TTL, fila de recuperação, análise e verificações de replicação assíncrona. - Monitoramento & Ops: Prometheus/Grafana, CloudWatch, alertas, runbooks automatizados. Interações de componentes (leitura): Usuário acessa URL curta -> Cache da borda verifica o redirecionamento em cache -> se encontrado, retorna o redirecionamento em cache (<5ms). Se não encontrado, a borda encaminha para o balanceador de carga regional -> Serviço de Redirecionamento consulta o cache Redis -> se encontrado, retorna o redirecionamento e a borda o armazena em cache; se não encontrado, o Serviço de Redirecionamento consulta o banco de dados primário -> retorna o redirecionamento -> Redis é atualizado e a borda armazena o redirecionamento em cache. Interações de componentes (escrita): Cliente chama a API -> API Gateway -> Serviço de Escrita -> Gerador de ID produz o token -> Serviço de Escrita grava o mapeamento no banco de dados primário com TTL -> Serviço de Escrita publica o evento no stream -> Serviço de Escrita grava no cache Redis e retorna a URL curta. Workers de background replicam assincronamente os eventos para análise e outras regiões, conforme necessário. Algoritmo de encurtamento de URL e estratégia de geração de chave Objetivos: token alfanumérico máximo de 7 caracteres, não adivinhável (sem tokens sequenciais), baixa probabilidade de colisão, comportamento de falha/tentativa reproduzível. Espaço e restrições: 62^7 ~= 3,52e12 tokens possíveis. O alvo mensal de 100 milhões de novos tokens é pequeno em relação ao espaço, mas devemos garantir que não haja enumeração fácil. Estratégia escolhida (primária): - Usar geração aleatória criptograficamente segura por URL curta nova. Gerar um inteiro aleatório criptograficamente seguro de 64 bits, aplicar amostragem por rejeição para mapear para o intervalo [0, 62^7 - 1] sem viés de módulo, e então codificar em base62 para exatamente 7 caracteres. Isso produz tokens uniformemente aleatórios em todo o espaço de 7 caracteres e sem sequencialidade. - Antes de confirmar, tentar uma inserção atômica no banco de dados com short_id como chave primária e unicidade garantida. Se a inserção falhar devido a uma colisão rara, tentar novamente com um novo token aleatório (probabilidade de colisão esperada insignificante; tentativas esperadas << 1). Por que não IDs sequenciais ou codificação bijetiva de um contador crescente: IDs sequenciais ou derivados de timestamp são adivinháveis e permitem enumeração e raspagem. Nós os rejeitamos para atender à não adivinhabilidade. Alternativa considerada e rejeitada: hashes criptográficos truncados da URL longa (por exemplo, os primeiros 7 caracteres base62 de SHA256). Rejeitada porque o mapeamento determinístico torna os tokens adivinháveis se o atacante puder fazer hash de URLs populares; também colisões mais frequentes ao truncar. Poderíamos ter usado HMAC(longURL, secret) para ser determinístico e não adivinhável, mas o mapeamento determinístico impede o reuso de tokens curtos em várias variações de entrada e complica o TTL/revogação. Esquema do banco de dados e tecnologia de armazenamento (com justificativa) Armazenamento primário escolhido: DynamoDB (AWS) ou Cassandra/Scylla gerenciado se auto-hospedado. Razão principal: gerenciado, escalável horizontalmente, alta taxa de leitura/escrita, suporte TTL integrado, replicação multirregional (Tabelas Globais do DynamoDB) e acesso de um único dígito de milissegundos se provisionado adequadamente. Isso é importante para 99,9% de uptime e operações simples. Esquema (lógico, estilo DynamoDB): - Tabela: url_map - Chave de Partição: short_id (string, 7 caracteres) - Atributos: long_url (string), created_at (timestamp), expires_at (timestamp), owner_id (string), metadata (blob JSON), version (int), deleted (boolean), deletion_marked_at (timestamp), click_count (numérico, opcional), analytics_shard_id (para particionamento de cliques) - Atributo TTL: expires_at para expiração automática pelo recurso TTL do DB Índices: nenhum índice secundário global adicional necessário para o caminho de redirecionamento. Opcionalmente, um GSI em owner_id para gerenciamento e exclusão em massa por usuário, e GSI em deletion_marked_at para processamento de recuperação. Justificativa: O padrão de acesso chave-valor mapeia-se claramente para o DynamoDB. O short_id é a chave única natural. O TTL é integrado. Para outros provedores de nuvem, use Cosmos DB com TTL ou Scylla/Cassandra com TTL por linha. Estratégia de cache e invalidação Objetivos: Alcançar 95º percentil de redirecionamento < 10ms em escala, minimizar a carga do DB, suportar multirregião. Camadas: - Cache da CDN (borda) de respostas de redirecionamento. A borda armazena em cache 301/302 com TTL de cache calculado a partir da expiração do mapeamento; TTL máximo de cache limitado ao TTL restante. Para URLs curtas recém-criadas, defina um TTL de cache curto para os primeiros N segundos para permitir a consistência. O cache da borda é o principal mecanismo para atingir a latência de 95º percentil < 10ms. - Cluster Redis regional (ElastiCache Redis Cluster com modo cluster ativado). O Redis armazena o mapeamento short_id -> resposta de redirecionamento serializada e metadados de expiração. O TTL de conjunto do Redis é igual à expiração do mapeamento. - Cache LRU local na memória (pequeno) no serviço de redirecionamento para acessos de microssegundos. Suposições de acerto de cache e dimensionamento: - Assumir taxa de acerto da CDN de 70% para URLs curtas (links populares); taxa de acerto do Redis para falhas de borda ~85% para padrões de acesso regionais. Estes são ajustáveis com base no uso. População e invalidação de cache: - Na escrita: o Serviço de Escrita grava no DB e imediatamente grava no Redis regional e publica um evento de invalidação de cache no stream, ao qual todas as regiões se inscrevem. Isso garante que os caches estejam aquecidos e consistentes em tempo quase real. - Na atualização ou exclusão: o Serviço de Escrita atualiza o DB e publica um evento de invalidação; os assinantes excluem chaves do Redis e invalidam caches da borda via cabeçalhos cache-control ou enviando PURGE/API de Cache para a CDN (ou definindo TTL de cache curto para 0 e deixando a borda buscar o fresco). Chamadas de purge são mantidas mínimas; preferimos expiração baseada em TTL e invalidação pub/sub. - Para expiração de TTL: confie no TTL do DB para remover a linha e nos workers de background para publicar um evento de invalidação para limpar caches e adicionar o token à fila de recuperação. Caminho de leitura (detalhado) e cálculos de taxa de transferência Cálculos de tráfego (mensal base -> por segundo): - Gravações: 100.000.000 / 30 / 24 / 3600 ~= 38,6 gravações/segundo em média. Fator de pico de 5 assumido para tráfego diurno/pico -> ~193 gravações/segundo no pico. - Leituras (redirecionamentos): 10.000.000.000 / 30 / 24 / 3600 ~= 3.858 leituras/segundo em média. Fator de pico de 5 -> ~19.290 leituras/segundo no pico. - Razão leitura/gravação: 100:1 conforme especificado. Caminho de leitura (otimizado para latência): 1. Cliente solicita short.example/abc1234 -> DNS resolve para o nó de borda da CDN. 2. Consulta de cache da borda: se o redirecionamento estiver em cache, retorna imediatamente HTTP 301/302. Isso cobre a maioria das solicitações para links populares. 3. Se a borda não encontrar em cache: a solicitação é encaminhada para o balanceador de carga regional -> Serviço de Redirecionamento. 4. O Serviço de Redirecionamento consulta o cache na memória (pequeno) -> Redis cluster get(short_id). O GET do Redis é sub-milissegundo, dependendo da rede (geralmente <1ms na região). Se o Redis encontrar em cache, o serviço retorna o redirecionamento e a borda o armazena em cache com TTL apropriado. 5. Se o Redis não encontrar em cache: o serviço consulta o banco de dados primário (DynamoDB GetItem), que é de um único dígito de ms, tipicamente 3-6ms. O serviço retorna o redirecionamento e popula o Redis e o cache da borda. Capacidade de taxa de transferência e exemplos de dimensionamento: - Cluster Redis: assumir pico de 20k leituras/segundo. Implantar 3-5 shards com replicação para lidar com 50k+ ops/segundo e fornecer margem. Cada shard dimensionado para ~10k ops/segundo (tipo de nó apropriado). Réplicas de leitura em cada AZ para alta disponibilidade. - DynamoDB: precisa de capacidade para gravações ~200 TPS no pico e leituras para falhas de cache. Se a taxa de acerto de cache for 90% no geral, a carga de leitura do DB = 19.290 * 0,10 ~= 1.929 leituras/segundo no pico. Com picos eventuais e fator de segurança 2, provisionar para 4k leituras/segundo com consistência forte (ou usar leituras com consistência eventual para reduzir o custo do RCU pela metade). Caminho de escrita (detalhado) e taxa de transferência Caminho de escrita: 1. Cliente envia solicitação de criação para a API -> API Gateway -> balanceador de carga regional -> Serviço de Escrita. 2. O Serviço de Escrita valida a URL (sanitização, verificações de malware opcionalmente), verifica limites de taxa e cotas. 3. Gerador de ID: usa CSPRNG para criar o token; tenta inserir no DB com PutItem condicional de que short_id não existe (atômico). Se PutItem falhar devido a chave existente (raro), tenta gerar novamente. A inserção inclui long_url, created_at, expires_at. 4. Após a inserção bem-sucedida, o Serviço de Escrita grava no Redis para aquecimento imediato do cache e publica um evento no stream para análise e propagação entre regiões. 5. Retorna a URL curta para o cliente. Dimensionamento da taxa de transferência para gravações: - Base de 39 gravações/segundo em média, pico provisionado ~200 gravações/segundo. O DynamoDB suporta facilmente milhares de gravações/segundo com capacidade apropriada ou modo sob demanda. - Serviço de Escrita sem estado escalado horizontalmente: assumir que cada instância pode lidar com 200-500 req/s; definir grupo de dimensionamento automático para manter a margem. Em 200 gravações/segundo no pico, 2-4 instâncias são suficientes; alocar 10-20 para redundância e outro processamento, como limitação de taxa. Estratégia de escalonamento e tratamento de crescimento 10x Cenário: crescimento 10x significa 1 bilhão de gravações/mês e 100 bilhões de redirecionamentos/mês. Estratégias: - Dimensionamento automático: Todos os serviços sem estado (Escrita/Redirecionamento) dimensionam automaticamente com base na CPU/RPS e latência da solicitação. Usar cluster autoscaler para contêineres. - Escalonamento de cache: Adicionar shards Redis e aumentar a memória. O modo cluster do Redis permite re-sharding dinâmico. A CDN lida com o escalonamento de borda automaticamente. - Escalonamento do DB: O DynamoDB suporta escalonamento sob demanda ou aumenta a capacidade de escrita/leitura; para Cassandra/Scylla auto-hospedado, adicione nós e rebalanceie tokens. - Particionamento: A chave hash do DynamoDB já distribui entre partições. Para Cassandra, certifique-se de que há nós suficientes para manter as partições pequenas. - Limitação de taxa e backpressure: Para picos repentinos, aplique limites de taxa por usuário e por chave de API e enfileire tarefas de background para trabalhos não críticos (análise). Implemente degradação graciosa (por exemplo, negar novas criações para clientes abusivos) em vez de impactar os redirecionamentos. - Tráfego global: Adicionar mais regiões e replicar dados. Adicionar réplicas de leitura Redis entre regiões ou confiar em cache local preenchido por leituras sob demanda. Estimativa de capacidade após 10x: - Picos de leitura ~200k/segundo. Com 90% de taxa de acerto de cache, leituras do DB no pico ~20k/segundo. DynamoDB/DAX ou cache gerenciado na frente do DB serão necessários. O cluster Redis escalará para centenas de shards, e a CDN permanecerá primária para reduzir a carga global. Implantação multirregional e modelo de consistência Modelo escolhido: multirregional ativo-ativo com consistência eventual entre regiões para dados não críticos. Usar Tabelas Globais do DynamoDB ou replicação multiregião da Cassandra. Justificativa e trade-offs CAP: - Requisito: 99,9% de uptime e recuperação de desastres entre regiões. Priorizar Disponibilidade e Tolerância a Partições (AP) em vez de Consistência estrita (CP) porque os redirecionamentos devem permanecer disponíveis mesmo durante partições de região. Um pequeno atraso na replicação para URLs curtas recém-criadas em outra região é aceitável; o usuário que criou a URL geralmente a usa imediatamente na mesma região e a verá devido à escrita local e ao aquecimento do cache. - Implementação: O Serviço de Escrita grava no DB da região local (DynamoDB local ou tabela da mesma região) e a replicação para outras regiões ocorre via tabelas globais. Leituras em uma região preferencialmente leem localmente. Para forte consistência de leitura após escrita local, use leitura com consistência forte do DynamoDB na mesma região imediatamente após a escrita, ou confie no aquecimento imediato do cache para garantir que o redirecionamento funcione na região do gravador. Trade-offs: - Consistência eventual simplifica a disponibilidade global e reduz a latência para leituras. Permite uma janela curta onde uma URL curta criada na região A pode não estar visível na região B até que a replicação termine. Aceitamos isso porque as principais SLAs se preocupam com a disponibilidade e latência dos redirecionamentos. - Se a consistência estrita entre regiões fosse necessária, teríamos que implementar um modelo CP com replicação síncrona entre regiões, o que aumentaria significativamente a latência de escrita e reduziria a disponibilidade durante partições; portanto, rejeitado. Expiração de TTL e mecanismo de recuperação de URL Requisitos: TTL configurável por URL curta (padrão de 5 anos), URLs expiradas devem ser recuperáveis. Mecanismo: - Usar atributo TTL do DB (expires_at). O DynamoDB exclui itens automaticamente após a passagem do TTL, mas a exclusão é eventualmente consistente e pode não ser imediata (pode levar até 48 horas em alguns sistemas). Portanto, implementamos um pipeline de recuperação ativo. - Quando expires_at se aproxima (por exemplo, dentro de 24 horas), os workers de background marcam a URL como expirando e enviam um evento pelo stream. Isso permite que os caches definam TTLs curtos e preparem a purga. - Na expiração real, os workers de background escaneiam linhas expiradas (usando GSI em deletion_marked_at ou eventos TTL da tabela) e movem a chave para uma Fila de Recuperação com metadados: short_id, deletion_marked_at, original_expires_at. - Política de recuperação: Introduzir um período de carência configurável (por exemplo, 30 dias) após a expiração, durante o qual o short_id é tombstoned (bandeira de exclusão e registro de tombstone retidos) para evitar reutilização imediata e para proteger contra atrasos de replicação e disputas de usuários. Durante o período de tombstone, o short_id resolve para 404 ou uma página "este link expirou"; cliques são registrados para auditoria. - Após o período de carência, o worker de recuperação move o short_id para um Pool de Tokens Recuperáveis (tópico Kafka ou tabela de pool de tokens DynamoDB). Tokens no pool podem ser reciclados; tokens recuperados incluem um cooldown e nunca são emitidos imediatamente para o mesmo proprietário, a menos que explicitamente solicitado. - Para evitar colisões de reutilização e abuso, manter um índice de tombstone para tokens usados recentemente (tamanho limitado, por exemplo, retidos por 1 ano em uma tabela separada) e verificar antes da reutilização. Alternativamente, em vez de reutilizar tokens, preferir manter a taxa de reciclagem extremamente baixa, já que o espaço de 7 caracteres é grande. Modos de falha e recuperação 1) Falha de CDN / Borda em uma região ou interrupção global do provedor de borda - Impacto: O cache da borda é interrompido; mais solicitações atingem os serviços de redirecionamento regionais e caches de backend, aumentando a carga e a latência. - Recuperação: O tráfego é redirecionado por DNS/anycast para outras bordas ou origem de fallback. Dimensionar automaticamente a frota de redirecionamento e aumentar o número de instâncias. Usar Origin Shield e configurar failover de origem. Servir redirecionamentos diretamente da origem até que a borda se recupere. 2) Falha da região do banco de dados primário (interrupção completa de AZ/região) - Impacto: DB local indisponível; gravações e leituras não podem ser atendidas dessa região. - Recuperação: Failover para outra região via tabelas globais. Redirecionar DNS e API Gateway para a(s) região(ões) saudável(is). Como os dados são replicados assincronamente, gravações recentes na região com falha podem ser perdidas por um curto período, a menos que as gravações tenham sido replicadas anteriormente. O sistema aceita isso em troca de alta disponibilidade. A reconciliação de background tenta reparar conflitos assim que a região retorna. 3) Falha ou partição do cluster Redis - Impacto: Aumento de falhas de cache levando a maior carga no DB e aumento da latência. - Recuperação: Clientes recorrem a leituras do DB; dimensionar a capacidade de leitura do DB ou habilitar DAX (DynamoDB Accelerator) ou nós Redis adicionais. Reconstruir o cluster Redis a partir de snapshots do DB ou aquecer caches via prefetch das chaves mais quentes usando análise/listas de chaves quentes. Usar Redis Sentinel ou cluster Redis gerenciado com failover automático para garantir redundância em nível de nó. 4) Bug no serviço gerador de ID causando colisões ou esgotamento de limite de taxa - Impacto: Falhas de gravação, erros de token duplicado ou incapacidade de criar novos tokens. - Recuperação: Projetar o gerador como CSPRNG sem estado; se um bug for detectado, reverter para uma versão estável anterior e rotear solicitações para uma implementação de gerador de fallback (por exemplo, uma biblioteca RNG diferente ou um contador de backup de curta duração combinado com um salt HMAC). Adicionar monitoramento na taxa de colisão; se a taxa de colisão > limite trivial, parar de emitir novos tokens e retornar 5xx até que seja corrigido. 5) Backlog do consumidor do stream de eventos ou falha do worker - Impacto: Invalidações de cache, processamento de análise e recuperação são atrasados. - Recuperação: Dimensionar automaticamente os consumidores, priorizar tópicos de invalidação e recuperação, e definir retenção para que novos consumidores possam alcançar. Reconstruir o estado a partir do DB, se necessário. Principais trade-offs e alternativas consideradas 1) Escolha de armazenamento: DynamoDB (NoSQL gerenciado) vs. RDBMS vs. Cassandra/Scylla - Escolhido: DynamoDB (ou Cassandra gerenciado). Razão: escala horizontal, TTL, serviço gerenciado, tabelas globais para multirregião. RDBMS rejeitado devido à complexidade de escalonamento, particionamento e latência de linha única mais lenta em escala extrema. 2) Geração de token: Token aleatório vs. contador sequencial vs. hash da URL longa - Escolhido: Tokens aleatórios criptograficamente seguros mapeados para base62 de 7 caracteres. Razão: não adivinhável, distribuição uniforme, escalonamento trivial, pequena probabilidade de colisão resolvida por inserção condicional no DB. Contadores sequenciais rejeitados porque são adivinháveis. Hash determinístico rejeitado devido ao maior risco de colisão e previsibilidade. 3) Multirregional ativo-ativo vs. failover ativo-passivo - Escolhido: Ativo-ativo com consistência eventual. Razão: melhor disponibilidade e roteamento de cliente mais simples para a região mais próxima com baixa latência. Ativo-passivo fornece consistência mais forte, mas aumenta o tempo de failover e pode violar os requisitos de latência/disponibilidade. 4) Recuperar tokens vs. nunca reutilizar tokens - Escolhido: Recuperável com período de carência/tombstone. Razão: o espaço de tokens é grande, então a reutilização não é necessária com frequência, mas a recuperação é exigida pela especificação. A segurança é aumentada pela retenção de tombstone e cooldown antes da reemissão. Nunca reutilizar rejeitado porque, após muitos anos, pode haver necessidade de conservar o namespace se os tokens se esgotarem em cenários patológicos. 5) Caching na borda vs. apenas origem direta - Escolhido: cache pesado na borda com TTLs curtos. Razão: atender latência de 95º percentil < 10ms para usuários globais. Apenas origem direta rejeitada porque a latência da origem e os saltos entre regiões excederiam o SLA de latência. Considerações operacionais e números - SLOs: 99,9% de uptime; monitorar saúde e latência na borda, redis, DB e serviço de escrita. Definir limites de alerta para taxas de erro e latência de 95º percentil. - Exemplos de planejamento de capacidade: para tráfego base, provisionar DB para ~4k leituras/segundo e ~200 gravações/segundo no pico; cluster Redis dimensionado para ~30k ops/segundo. Para escala 10x, provisionar DB para ~40k leituras/segundo e Redis para ~300k ops/segundo com shards de dimensionamento automático. - Mitigação de segurança e abuso: limitação de taxa por chave de API/IP, varredura de URL para malware (assíncrono opcional), aplicação de cotas por conta. - Retenção de dados e privacidade: Fornecer APIs de gerenciamento para usuários excluírem/estenderem TTL; semântica de exclusão lógica para auditabilidade e retenção de tombstone. Resumo Este projeto usa uma abordagem de cache em várias camadas (borda CDN + Redis regional) suportada por um armazenamento NoSQL escalável horizontalmente (DynamoDB ou Cassandra) e microsserviços sem estado para atender aos requisitos de taxa de transferência e latência. A geração de tokens usa tokens base62 de 7 caracteres baseados em CSPRNG com resolução de colisão baseada em DB para garantir a não adivinhabilidade. O sistema favorece a disponibilidade e a tolerância a partições (consistência eventual multirregional ativo-ativo) para atender aos SLAs de uptime e latência, enquanto a recuperação e o TTL são tratados pelo TTL do DB mais um pipeline de recuperação com uma janela de carência de tombstone para evitar reutilização acidental. A arquitetura escala horizontalmente com dimensionamento automático e particionamento para acomodar o crescimento 10x, e inclui caminhos de recuperação para modos de falha comuns para atender à meta de 99,9% de uptime.

Este projeto de sistema descreve um serviço de encurtamento de URL robusto, escalável e altamente disponível, capaz de lidar com 100 milhões de novos encurtamentos e 10 bilhões de redirecionamentos por mês, com requisitos rigorosos de latência e tempo de atividade. Descrição da Arquitetura de Alto Nível: A arquitetura é projetada para alta disponibilidade, escalabilidade e baixa latência, aproveitando uma abordagem de microsserviços. Os componentes principais incluem: 1. **Balanceadores de Carga (ex: AWS ELB/GCP Load Balancer/Nginx)**: Distribuem o tráfego de entrada entre as instâncias do serviço. 2. **API Gateway (ex: AWS API Gateway/Kong)**: Lida com requisições de API, autenticação, limitação de taxa e roteia o tráfego para os serviços de backend apropriados. 3. **Serviço de Encurtamento (Caminho de Escrita)**: Um microsserviço sem estado responsável por processar requisições para criar novas URLs curtas. Interage com o Serviço de Geração de Chaves e o Banco de Dados. 4. **Serviço de Redirecionamento (Caminho de Leitura)**: Um microsserviço sem estado altamente otimizado, responsável por resolver URLs curtas para URLs longas e realizar o redirecionamento HTTP 301/302. Depende fortemente de cache. 5. **Serviço de Geração de Chaves**: Um serviço dedicado responsável por pré-gerar e gerenciar um pool de chaves de URL curta únicas e aleatórias. Garante que não sejam adivinháveis e evita colisões. 6. **Banco de Dados (ex: Apache Cassandra)**: O armazenamento persistente primário para mapeamentos de URL curta. Escolhido por sua alta taxa de transferência de escrita/leitura, escalabilidade horizontal e capacidades de replicação multirregional. 7. **Cache Distribuído (ex: Redis Cluster)**: Armazena mapeamentos de URL curta acessados com frequência para reduzir a carga do banco de dados e alcançar baixa latência de redirecionamento. 8. **Fila de Mensagens (ex: Apache Kafka/AWS SQS)**: Usada para comunicação assíncrona entre serviços, como publicação de eventos para análise, invalidação de cache e expiração de URL. 9. **Serviço de Análise**: Consome eventos da fila de mensagens para rastrear contagens de cliques, gerar relatórios e monitorar padrões de uso. 10. **Serviço de Expiração e Recuperação**: Um serviço de worker em segundo plano responsável por identificar URLs expiradas, marcá-las e retornar suas chaves para o pool do Serviço de Geração de Chaves para reutilização. 11. **CDN (Rede de Entrega de Conteúdo, ex: Cloudflare/Akamai)**: Opcional, mas altamente recomendado para cache de redirecionamentos na borda, reduzindo ainda mais a latência e a carga do servidor de origem para usuários globais. Interações: * **Caminho de Escrita**: Usuário -> Balanceador de Carga -> API Gateway -> Serviço de Encurtamento -> Serviço de Geração de Chaves (obtém chave) -> Banco de Dados (escreve mapeamento) -> Fila de Mensagens (publica evento 'new_url') -> Cache (atualiza/escreve através). * **Caminho de Leitura**: Usuário -> Balanceador de Carga -> CDN (se atingido, redireciona) -> Serviço de Redirecionamento (verifica cache local -> cache distribuído -> banco de dados) -> Redirecionamento. Algoritmo de Encurtamento de URL e Estratégia de Geração de Chaves: Para garantir que não sejam adivinháveis, sejam únicas e atendam ao limite de 7 caracteres, uma estratégia de pré-geração é empregada: 1. **Serviço de Geração de Chaves**: Este serviço gera continuamente strings alfanuméricas aleatórias de 7 caracteres (ex: usando um gerador de números pseudoaleatórios criptograficamente seguro). O conjunto de caracteres inclui `a-z`, `A-Z`, `0-9`, totalizando 62 caracteres. Uma string de 7 caracteres permite 62^7 chaves únicas, o que é aproximadamente 3,5 trilhões, excedendo em muito o requisito de 100 milhões de URLs/mês. 2. **Verificação de Unicidade**: Antes de adicionar ao pool, cada chave gerada é verificada quanto à unicidade em relação ao banco de dados (ou um armazenamento de chaves único dedicado). Esta é uma verificação única durante a geração, não durante as requisições de encurtamento. 3. **Pool de Chaves**: Chaves únicas são armazenadas em um pool de acesso rápido e altamente disponível (ex: um Conjunto Redis ou uma tabela dedicada no Cassandra com um campo 'status' como 'disponível'). O Serviço de Geração de Chaves mantém um grande buffer (ex: vários bilhões de chaves) para garantir que as chaves estejam sempre prontamente disponíveis. 4. **Processo de Encurtamento**: Quando um usuário solicita uma nova URL curta, o Serviço de Encurtamento solicita uma chave ao Serviço de Geração de Chaves. O Serviço de Geração de Chaves remove atomicamente uma chave disponível de seu pool, marca-a como 'em uso' e a retorna. Isso evita contenção em cargas de escrita elevadas. 5. **Evitação de Colisões**: Ao pré-gerar e atribuir atomicamente chaves únicas, as colisões durante a requisição de encurtamento real são virtualmente eliminadas. O banco de dados também impõe uma restrição única na `short_url_key` como uma salvaguarda final. Esquema do Banco de Dados e Escolha da Tecnologia de Armazenamento: Escolha do Banco de Dados: **Apache Cassandra** (ou AWS DynamoDB como alternativa gerenciada). Justificativa: * **Alta Taxa de Transferência de Escrita/Leitura**: O Cassandra é projetado para operações de alto volume e baixa latência, perfeito para a proporção de leitura para escrita de 100:1 e bilhões de leituras. * **Escalabilidade Horizontal**: Escala facilmente adicionando mais nós, distribuindo dados e carga pelo cluster. * **Alta Disponibilidade e Tolerância a Falhas**: Os dados são replicados em vários nós e data centers, garantindo operação contínua mesmo durante falhas de nós. * **Consistência Eventual**: Aceitável para este caso de uso. Embora uma nova URL possa levar milissegundos para se propagar entre regiões, isso não afeta a funcionalidade principal. * **Consultas Simples de Chave-Valor**: O padrão de acesso primário é `short_url_key` para `long_url`, no qual o Cassandra se destaca. Esquema (Keyspace: `url_shortener`, Tabela: `short_urls`): ``` CREATE TABLE url_shortener.short_urls ( short_url_key text PRIMARY KEY, -- Chave de Partição, 7 caracteres alfanuméricos long_url text, user_id text, -- Opcional, para URLs específicas do usuário created_at timestamp, expires_at timestamp, click_count counter, -- Tipo de contador do Cassandra para incrementos atômicos status text -- 'active', 'expired', 'reclaimed' ); ``` Estratégia de Cache e Abordagem de Invalidação de Cache: O cache é fundamental para alcançar a latência de redirecionamento <10ms e lidar com 10 bilhões de redirecionamentos/mês. Estratégia: 1. **Cache de Múltiplos Níveis**: * **CDN (Cache de Borda)**: Armazena em cache redirecionamentos em pontos de presença geograficamente distribuídos. Esta é a primeira linha de defesa para requisições de leitura. * **Cache Distribuído (Redis Cluster)**: Um cache central de alto desempenho armazenando mapeamentos de `short_url_key` para `long_url`. Cada entrada também armazena `expires_at`. * **Cache em Memória**: Cada instância do Serviço de Redirecionamento mantém um pequeno e rápido cache em memória para as URLs mais acessadas. 2. **Read-Through**: Quando o Serviço de Redirecionamento recebe uma requisição, ele primeiro verifica seu cache em memória, depois o Redis Cluster. Se não for encontrado, ele busca no Cassandra, armazena o mapeamento no Redis e em seu cache local, e então redireciona. 3. **Write-Through**: Quando uma nova URL é encurtada, o Serviço de Encurtamento grava o mapeamento no Cassandra e, em seguida, grava imediatamente no Redis Cluster. Invalidação de Cache: 1. **Expiração Baseada em TTL**: As entradas de cache no Redis e nos caches em memória têm um TTL configurável (ex: 5 minutos ou alinhado com o `expires_at` da URL). Isso lida com a consistência eventual e garante que dados desatualizados não persistam indefinidamente. 2. **Invalidação Explícita**: Quando uma URL expira ou é recuperada pelo Serviço de Expiração e Recuperação, um evento é publicado na Fila de Mensagens. Workers de invalidação de cache consomem este evento e excluem explicitamente a entrada correspondente do Redis Cluster. Os caches da CDN são invalidados via chamadas de API ou definindo cabeçalhos `Cache-Control` apropriados com `max-age` curto para redirecionamentos. Caminho de Leitura e Caminho de Escrita com Cálculos de Taxa de Transferência: Suposições: 1 mês = 2.592.000 segundos. Caminho de Escrita (100 milhões de novos encurtamentos de URL por mês): * **Taxa de Transferência Média**: 100.000.000 URLs / 2.592.000 segundos ≈ 38,6 escritas/segundo. * **Taxa de Transferência de Pico**: Assumindo que o pico seja 3x a média, projetar para ~120 escritas/segundo. * **Fluxo**: Balanceador de Carga -> API Gateway -> Serviço de Encurtamento (solicita chave ao Serviço de Geração de Chaves, escreve no Cassandra, escreve no Redis, publica evento no Kafka). * **Componentes**: Múltiplas instâncias do Serviço de Encurtamento, Serviço de Geração de Chaves, nós Cassandra, nós Redis, brokers Kafka. * **Meta de Latência**: Abaixo de 100ms para escritas (menos crítico que leituras). Caminho de Leitura (10 bilhões de redirecionamentos por mês): * **Taxa de Transferência Média**: 10.000.000.000 redirecionamentos / 2.592.000 segundos ≈ 3.858 leituras/segundo. * **Taxa de Transferência de Pico**: Assumindo que o pico seja 3x a média, projetar para ~12.000 leituras/segundo. * **Fluxo**: Usuário -> CDN (se atingido, redireciona) -> Balanceador de Carga -> Serviço de Redirecionamento (verifica cache em memória -> Redis Cluster -> Cassandra) -> Redirecionamento. * **Taxa de Acerto de Cache**: Almejar >95% de taxa de acerto de cache (CDN + Redis) para descarregar o Cassandra. * **Leituras Efetivas do DB**: 12.000 leituras/seg * 5% (falha de cache) = 600 leituras/segundo para o Cassandra. * **Meta de Latência**: Abaixo de 10ms no percentil 95. * **Componentes**: Numerosas instâncias do Serviço de Redirecionamento, nós Redis Cluster, nós Cassandra. A CDN desempenha um papel crucial. Estratégia de Escalabilidade: 1. **Escalabilidade Horizontal (Serviços sem Estado)**: Todos os serviços sem estado (API Gateway, Serviço de Encurtamento, Serviço de Redirecionamento, Serviço de Geração de Chaves, Serviço de Análise, Serviço de Expiração e Recuperação) são implantados como múltiplas instâncias atrás de balanceadores de carga. Eles podem ser escalados adicionando mais instâncias com base na utilização da CPU, memória ou profundidade da fila de requisições (ex: usando Kubernetes HPA ou AWS Auto Scaling Groups). 2. **Escalabilidade do Banco de Dados (Cassandra)**: O Cassandra escala horizontalmente adicionando mais nós ao cluster. Os dados são rebalanceados automaticamente. Isso permite aumentar a capacidade de armazenamento e a taxa de transferência de leitura/escrita. 3. **Escalabilidade do Cache (Redis Cluster)**: O Redis Cluster fornece particionamento e replicação, permitindo que ele escale horizontalmente adicionando mais nós master e réplica. 4. **Escalabilidade da Fila de Mensagens (Kafka)**: O Kafka é inerentemente escalável, permitindo aumentar a taxa de transferência adicionando mais brokers e partições. 5. **CDN**: Descarrega uma porção significativa do tráfego de leitura dos servidores de origem, escalando efetivamente o caminho de leitura globalmente. 6. **Microsserviços**: A arquitetura modular permite que serviços individuais sejam escalados independentemente com base em seus requisitos de carga específicos. Implantação Multirregional e Modelo de Consistência de Dados: Para alcançar 99,9% de tempo de atividade e recuperação de desastres, o serviço será implantado em uma configuração Ativa-Ativa em pelo menos duas regiões geográficas (ex: US-East e EU-West). Implantação: * Cada região hospeda uma pilha completa e independente de todos os serviços (Balanceadores de Carga, API Gateway, Serviços de Encurtamento/Redirecionamento, Serviço de Geração de Chaves, cluster Cassandra, cluster Redis, cluster Kafka, etc.). * Um Balanceador de Carga Global (ex: AWS Route 53 com roteamento baseado em latência ou um gerenciador de tráfego global) direciona os usuários para a região saudável mais próxima. Modelo de Consistência de Dados: * **Replicação de Cassandra Multirregional**: A `NetworkTopologyStrategy` do Cassandra é usada para replicar dados assincronamente entre os clusters regionais. Cada região mantém uma cópia completa dos dados. * **Escritas**: As escritas são tipicamente realizadas com consistência `LOCAL_QUORUM` dentro da região primária para baixa latência. A replicação integrada do Cassandra garante a consistência eventual entre as regiões. Uma nova URL curta criada na Região A eventualmente se propagará para a Região B. * **Leituras**: As leituras também são tipicamente realizadas com consistência `LOCAL_QUORUM` para baixa latência, servindo dados do cluster Cassandra ou cache da região local. Se uma chave não for encontrada localmente (ex: devido ao atraso de replicação para uma URL muito nova), um fallback para uma leitura entre regiões pode ser implementado, mas isso incorreria em latência mais alta. Dado a natureza de leitura intensiva e o cache, isso é raro. Trade-offs (Teorema CAP): * **Escolhido**: Priorizar **Disponibilidade** e **Tolerância a Partições** em detrimento da **Consistência** forte entre regiões. * **Raciocínio**: Para um serviço de encurtamento de URL, é mais crítico que o serviço esteja sempre disponível e tenha desempenho rápido, mesmo que uma URL recém-criada leve alguns milissegundos para ser acessível globalmente. A consistência forte entre data centers geograficamente dispersos introduziria latência de escrita e complexidade inaceitáveis. Mecanismo de Expiração de TTL e Recuperação de URL: 1. **Expiração**: O timestamp `expires_at` na tabela `short_urls` é usado. O Serviço de Expiração e Recuperação (um conjunto de workers em segundo plano) escaneia periodicamente a tabela `short_urls` em busca de entradas onde `expires_at` está no passado e o `status` é 'active'. * Ao identificar uma URL expirada, o serviço atualiza seu `status` para 'expired' no Cassandra. * Em seguida, publica um evento 'url_expired' na Fila de Mensagens, acionando a invalidação de cache para essa `short_url_key` no Redis e na CDN. 2. **Recuperação**: Após um período de carência configurável (ex: 24-48 horas) após a expiração (para garantir que todos os caches sejam limpos e nenhum redirecionamento em andamento seja afetado), o Serviço de Expiração e Recuperação identifica URLs com `status` 'expired' que estão além de seu período de carência. * Em seguida, atualiza seu `status` para 'reclaimable'. * A `short_url_key` é então adicionada de volta ao pool de chaves disponíveis do Serviço de Geração de Chaves. Isso garante que o espaço de chaves de 7 caracteres seja eficientemente reutilizado ao longo do tempo. * Uma verificação final de unicidade antes de adicionar de volta ao pool pode ser feita, embora o design do Serviço de Geração de Chaves deva prevenir colisões reais. Modos de Falha e Recuperação: 1. **Falha de Nó do Banco de Dados (ex: crash de nó Cassandra)**: * **Detecção**: Sistemas de monitoramento detectam a inacessibilidade do nó ou altas taxas de erro. * **Recuperação**: A arquitetura distribuída do Cassandra com um fator de replicação (RF) de 3 (ou superior) garante a redundância de dados. Se um nó falhar, outras réplicas servem os dados. O cluster permanece operacional. O nó com falha pode ser substituído automaticamente ou trazido de volta online manualmente. Nenhuma perda de dados, interrupção mínima do serviço. 2. **Falha do Serviço de Geração de Chaves**: * **Detecção**: Verificações de integridade e monitoramento detectam a indisponibilidade do serviço ou o esgotamento do pool de chaves. * **Recuperação**: O Serviço de Geração de Chaves é implantado com múltiplas instâncias. Se uma falhar, outras assumem. Se todo o serviço falhar, as novas requisições de encurtamento de URL falharão temporariamente, pois não conseguirão obter uma chave única. No entanto, os redirecionamentos existentes continuarão funcionando normalmente. Grupos de autoescalonamento iniciarão novas instâncias. Um grande buffer de chaves pré-geradas (bilhões de chaves) reduz significativamente o impacto de interrupções temporárias. 3. **Falha do Cluster de Cache (ex: interrupção do Redis Cluster)**: * **Detecção**: Monitoramento detecta a indisponibilidade do nó ou cluster Redis. * **Recuperação**: O Serviço de Redirecionamento é projetado para fazer fallback para o banco de dados Cassandra se o cache estiver indisponível. Isso levará a um aumento na latência de redirecionamento (de <10ms para potencialmente 50-100ms) e maior carga no Cassandra, mas o serviço permanecerá totalmente funcional (desempenho degradado). O Redis Cluster com replicação fornece alta disponibilidade, mitigando falhas completas do cluster. 4. **Falha de Região Inteira**: * **Detecção**: O Balanceador de Carga Global (ex: verificações de integridade do Route 53) detecta que todos os serviços em uma região estão indisponíveis. * **Recuperação**: O Balanceador de Carga Global roteia automaticamente todo o tráfego para a região secundária saudável. Os usuários podem experimentar um breve pico de latência durante o failover, mas o serviço permanece disponível. A consistência dos dados pode estar ligeiramente atrasada, mas o sistema é projetado para tolerar consistência eventual. Principais Trade-offs Feitos e Alternativas Consideradas: 1. **Consistência vs. Disponibilidade/Latência (Teorema CAP)**: * **Escolhido**: Consistência eventual para replicação de dados entre regiões e alta disponibilidade/baixa latência de leituras. * **Rejeitado**: Consistência forte entre regiões. * **Raciocínio**: A consistência forte introduziria latência significativa para escritas e leituras entre regiões, o que é inaceitável para um serviço de redirecionamento de alta taxa de transferência e baixa latência. Alguns milissegundos de inconsistência para um mapeamento de URL recém-criado são um pequeno trade-off em comparação com os benefícios de alta disponibilidade e desempenho. 2. **Estratégia de Geração de Chaves (Pré-geradas vs. Hashing/Sequencial On-the-fly)**: * **Escolhido**: Chaves alfanuméricas aleatórias pré-geradas através de um serviço dedicado. * **Rejeitado**: Hashing da URL longa (ex: MD5, SHA-256 truncado) ou uso de um codificador base-62 em um ID auto-incrementável. * **Raciocínio**: O hashing pode levar a colisões (especialmente com um limite de 7 caracteres) exigindo lógica complexa de resolução de colisões, adicionando latência e complexidade ao caminho de escrita. Base-62 em IDs auto-incrementáveis torna as URLs sequenciais e adivinháveis, violando um requisito chave. A pré-geração garante unicidade, não adivinhabilidade e recuperação rápida de chaves durante as escritas, simplificando o processo de encurtamento. 3. **Escolha do Banco de Dados (NoSQL vs. Relacional SQL)**: * **Escolhido**: Apache Cassandra (NoSQL). * **Rejeitado**: PostgreSQL/MySQL (Relacional SQL). * **Raciocínio**: Bancos de dados relacionais lutam com a taxa de transferência extrema de leitura/escrita e os requisitos de escalabilidade horizontal deste serviço sem complexidade de particionamento significativa. Bancos de dados NoSQL como Cassandra são construídos especificamente para essa escala, alta disponibilidade e desempenho, especialmente para consultas simples de chave-valor, que é o padrão de acesso primário. 4. **Implementação de TTL (Serviço em Segundo Plano vs. TTL do Banco de Dados)**: * **Escolhido**: Serviço dedicado de Expiração e Recuperação escaneando `expires_at`. * **Rejeitado**: Confiar apenas no TTL em nível de banco de dados (ex: TTL integrado do Cassandra). * **Raciocínio**: Embora o TTL do banco de dados possa expirar dados automaticamente, ele não facilita facilmente a recuperação controlada da `short_url_key` de volta para um pool reutilizável ou aciona a invalidação explícita do cache. Um serviço dedicado fornece controle mais granular sobre todo o ciclo de vida, incluindo o período de carência e a reutilização segura de chaves.