Projetar um serviço de encurtamento de URLs em larga escala

### A. Arquitetura de Alto Nível O sistema é projetado como um conjunto de microsserviços distribuídos e sem estado, implantados em várias regiões geográficas para garantir alta disponibilidade e baixa latência. Os principais componentes são: 1. **Balanceador de Carga Global (GLB)**: Distribui o tráfego do usuário para a região mais próxima e saudável usando roteamento baseado em DNS (por exemplo, AWS Route 53, Google Cloud Load Balancing). 2. **Balanceadores de Carga Regionais (RLB)**: Distribuem o tráfego dentro de uma única região para a frota de servidores web. 3. **API Gateway / Servidores Web**: Uma camada de servidores sem estado que encerra TLS e lida com requisições HTTP de entrada tanto para escrita (encurtamento) quanto para leitura (redirecionamento). 4. **Serviço de Redirecionamento (Caminho de Leitura)**: Um serviço altamente otimizado responsável por procurar códigos curtos e emitir redirecionamentos HTTP 301/302. Ele interage principalmente com a camada de cache. 5. **Serviço de Encurtamento de URL (Caminho de Escrita)**: Um serviço que lida com a criação de novas URLs curtas. Ele coordena com o Serviço de Geração de Chaves e o banco de dados principal. 6. **Cache Distribuído**: Um cache em memória (por exemplo, Redis Cluster) em cada região que armazena mapeamentos de URL quentes para atender ao requisito estrito de baixa latência para redirecionamentos. 7. **Banco de Dados Principal**: Um banco de dados NoSQL distribuído (por exemplo, Apache Cassandra, Amazon DynamoDB) que serve como a fonte de verdade persistente para todos os mapeamentos de URL, replicado em todas as regiões. 8. **Serviço de Geração de Chaves (KGS)**: Um serviço dedicado e altamente disponível que pré-gera lotes de códigos curtos únicos de 7 caracteres para eliminar colisões e latência no momento da escrita. 9. **Pipeline de Análise**: Um pipeline de dados assíncrono que começa com uma fila de mensagens (por exemplo, Apache Kafka) para ingerir dados de clickstream sem impactar o desempenho do serviço de redirecionamento. Esses dados são então processados e armazenados em um banco de dados de análise separado. ### B. Estratégia de Geração de URL **Abordagem**: Usaremos um Serviço de Geração de Chaves (KGS) dedicado para pré-gerar chaves únicas. **Mecanismo**: 1. O KGS mantém um contador de forma distribuída e tolerante a falhas (por exemplo, usando ZooKeeper ou um contador atômico em um banco de dados como Redis). 2. Ele gera IDs numéricos grandes e sequenciais. Para garantir alta disponibilidade, várias instâncias do KGS podem ser executadas, cada uma responsável por uma faixa diferente de IDs (por exemplo, Servidor 1 lida com 1 a 1.000.000, Servidor 2 lida com 1.000.001 a 2.000.000). 3. Cada ID numérico é então convertido para uma string base-62 ([a-z, A-Z, 0-9]) para produzir o código curto de 7 caracteres. Um espaço de 62^7 fornece aproximadamente 3,5 trilhões de códigos únicos, o que é mais do que suficiente. 4. O KGS gera esses códigos em lotes e os coloca em uma fila (por exemplo, uma lista Redis) para o Serviço de Encurtamento de URL consumir. **Justificativa**: Essa abordagem evita a necessidade de verificar colisões no banco de dados principal durante uma operação de escrita, o que seria lento e um ponto de contenção. Ela torna o caminho de escrita extremamente rápido e previsível, pois o Serviço de Encurtamento simplesmente precisa buscar uma chave garantidamente única do KGS. ### C. Modelo de Dados e Armazenamento **Armazenamento Principal (Mapeamentos de URL)**: * **Tecnologia**: Apache Cassandra ou Amazon DynamoDB. * **Por quê**: Esses bancos de dados NoSQL oferecem excelente escalabilidade horizontal, replicação nativa multirregional, alta disponibilidade e consultas de chave-valor de baixa latência, que correspondem perfeitamente aos nossos requisitos de escala e tolerância a falhas. * **Esquema**: * Nome da Tabela: `url_mappings` * Chave de Partição: `short_code` (string) * Colunas: * `long_url` (string) * `user_id` (string, para propriedade) * `created_at` (timestamp) **Armazenamento de Cache**: * **Tecnologia**: Redis Cluster. * **Por quê**: O Redis fornece acesso a dados em memória de latência extremamente baixa (sub-milissegundo), o que é essencial para atender ao requisito de redirecionamento <10ms. Ele pode ser clusterizado para escalabilidade e alta disponibilidade. **Armazenamento de Análise**: * **Tecnologia**: Um banco de dados orientado a colunas como Apache Druid, ClickHouse, ou um data warehouse na nuvem como Google BigQuery. * **Por quê**: Esses sistemas são otimizados para agregações rápidas e consultas analíticas sobre conjuntos de dados massivos, o que é ideal para alimentar o painel de análise. ### D. Otimização do Caminho de Leitura O caminho de leitura é fortemente otimizado para latência usando uma estratégia de cache em várias camadas para lidar com os 40.000 QPS de pico. 1. **CDN/Cache de Borda**: Para URLs extremamente populares, uma CDN pode armazenar em cache a resposta de redirecionamento 301/302 nos locais de borda, servindo os usuários do ponto de presença mais próximo sem atingir nossa infraestrutura principal. 2. **Cache Distribuído em Memória (Redis)**: Este é o principal motor para baixa latência. O Serviço de Redirecionamento primeiro consulta o cluster Redis regional. Um acerto de cache resulta em um redirecionamento imediato. * **Estimativa de Tamanho do Cache**: Para armazenar em cache 20% de 5 anos de URLs (100M/mês * 12 * 5 * 0.2 = 1,2 bilhão de URLs). Com ~600 bytes por entrada (código curto, URL longa, sobrecarga), isso requer aproximadamente 720 GB de RAM por região, o que é viável para um cluster Redis. 3. **Consulta ao Banco de Dados**: Em caso de falha no cache, o serviço consulta o banco de dados principal Cassandra/DynamoDB. O resultado é então gravado de volta no cache Redis com um Tempo de Vida (TTL) para garantir que o cache permaneça preenchido com itens acessados com frequência. Essa arquitetura garante que a grande maioria das requisições seja atendida a partir da memória, atendendo facilmente à meta de latência p99 <10ms. ### E. Caminho de Escrita O caminho de escrita é projetado para confiabilidade e taxa de transferência (~400 escritas de pico/segundo). 1. Um usuário envia uma requisição POST com a URL longa para o API Gateway. 2. A requisição é roteada para uma instância do Serviço de Encurtamento de URL. 3. O serviço valida a URL longa. 4. Ele solicita um código curto único do Serviço de Geração de Chaves (KGS). 5. O serviço grava o novo mapeamento (`short_code`, `long_url`) no banco de dados principal (Cassandra/DynamoDB) com um alto nível de consistência para a região local. 6. O banco de dados replica assincronamente essa escrita para outras regiões. 7. Após a gravação bem-sucedida no banco de dados, o serviço retorna a nova URL curta para o usuário. ### F. Estratégia de Escalabilidade O sistema é projetado para escalar horizontalmente em todas as camadas: * **Serviços sem Estado**: O API Gateway, o Serviço de Redirecionamento e o Serviço de Encurtamento são sem estado. Podemos escalá-los adicionando mais máquinas virtuais ou contêineres atrás dos balanceadores de carga. * **Banco de Dados**: Cassandra e DynamoDB são projetados para escalar horizontalmente adicionando mais nós ao cluster. Os dados e a carga são rebalanceados automaticamente. * **Cache**: O Redis Cluster pode ser escalado adicionando mais nós e re-particionando o keyspace. * **Pipeline de Análise**: O Kafka escala adicionando mais brokers e partições. Os serviços consumidores que processam os dados também podem ser escalados horizontalmente. ### G. Confiabilidade e Tolerância a Falhas A alta disponibilidade é alcançada através de redundância em várias regiões geográficas (por exemplo, US-East, US-West, EU-West). * **Implantação Multirregional**: Toda a pilha é implantada em pelo menos duas regiões independentes. * **Failover Global**: O Balanceador de Carga Global monitora continuamente a saúde de cada região. Se uma região inteira ficar indisponível, o GLB redireciona automaticamente todo o tráfego para as regiões saudáveis. * **Replicação de Dados**: O banco de dados principal (Cassandra/DynamoDB) é configurado para replicação multirregional. Isso garante que, se um banco de dados regional for perdido, os dados serão preservados em outras regiões. As escritas podem continuar a ser atendidas nas regiões ativas restantes. * **Sem Ponto Único de Falha**: Cada componente, desde os balanceadores de carga até o KGS e os bancos de dados, é implantado em uma configuração clusterizada e tolerante a falhas. ### H. Pipeline de Análise O pipeline de análise é projetado para ser completamente desacoplado do caminho de redirecionamento crítico para evitar qualquer degradação de desempenho. 1. **Ingestão de Dados**: Após atender com sucesso a um redirecionamento, o Serviço de Redirecionamento publica uma mensagem em um tópico Kafka. Essa mensagem contém dados de eventos como `short_code`, `timestamp`, `IP address`, `User-Agent` e `Referrer`. Esta é uma operação assíncrona e não bloqueante. 2. **Processamento de Dados**: Uma frota separada de workers de processamento de fluxo (por exemplo, usando Spark Streaming, Flink ou consumidores personalizados) lê mensagens do tópico Kafka em lotes. 3. **Enriquecimento e Agregação de Dados**: Esses workers enriquecem os dados (por exemplo, convertendo IP em geolocalização) e realizam agregações em tempo real (por exemplo, incrementando contagens de cliques por hora, por país). 4. **Armazenamento de Dados**: Os dados processados e agregados são carregados no banco de dados de análise (ClickHouse/Druid), que é otimizado para alimentar as consultas do painel voltado para o usuário de forma eficiente. Essa arquitetura assíncrona garante que mesmo um pico massivo de tráfego ou uma falha no pipeline de análise terá impacto zero na velocidade e disponibilidade dos redirecionamentos de URL. ### I. Principais Compromissos (Trade-offs) 1. **Consistência Eventual vs. Consistência Forte**: Escolhemos um modelo de replicação de dados eventualmente consistente entre regiões. Uma URL criada em uma região pode levar milissegundos para estar disponível em outra. Esse trade-off melhora significativamente a latência de escrita e a disponibilidade do sistema, que são mais críticas para esta aplicação do que a consistência global imediata. 2. **Custo vs. Desempenho**: Estamos usando um cache grande e caro em memória Redis para atender ao requisito estrito de latência p99 <10ms. Uma solução mais barata baseada em disco não seria capaz de satisfazer este SLA de desempenho principal. Estamos trocando um custo operacional mais alto por baixa latência garantida no caminho de leitura crítico. 3. **Complexidade vs. Escalabilidade (KGS)**: Introduzimos um Serviço de Geração de Chaves (KGS) separado em vez de gerar hashes ou strings aleatórias sob demanda. Isso adiciona um componente extra para construir e manter, aumentando a complexidade do sistema. No entanto, elimina completamente os hotspots do banco de dados e a lógica de verificação de colisão no caminho de escrita, o que é um trade-off crucial para garantir alta taxa de transferência e escritas de baixa latência em escala.

Resumo Proponho um encurtador de URL globalmente distribuído e com prioridade para cache, com: um caminho de redirecionamento de borda leve (CDN + função de borda + cache local) para atender ao requisito de latência de redirecionamento p99 <10 ms; um armazenamento primário durável e multirregional para mapeamentos canônicos; um alocador de ID distribuído para gerar códigos curtos exclusivos codificados em base62 (<=7 caracteres); um pipeline de análise assíncrono (Kafka/Kinesis → processadores de stream → armazenamento OLAP) que é estritamente desacoplado do caminho de redirecionamento; e replicação e failover multirregionais para disponibilidade durante uma interrupção completa do data center. A. Arquitetura de alto nível (componentes e interações) - Camada de borda (CDN): CDN na nuvem (por exemplo, Amazon CloudFront, Fastly) atende a todas as solicitações GET /{code} de redirecionamento. A maioria das solicitações é atendida pelo cache de borda da CDN com uma resposta 301/302 em cache. - Função de borda (CloudFront Function / Fastly Compute / Lambda@Edge): em caso de cache miss, uma pequena função de borda invoca uma API de Redirecionamento regional (via RPC/HTTP curto) para buscar o URL de destino canônico e retornar um 301/302. A função de borda adiciona lógica mínima para escolher o TTL de cache correto e lidar com códigos excluídos/ausentes. - API de Redirecionamento Regional / Camada de Cache de Leitura: servidores de leitura sem estado em cada região que primeiro consultam um cache regional em memória (cluster Redis / ElastiCache ou Memcached) e depois recorrem ao armazenamento durável de chave-valor, se necessário. - Armazenamento durável de chave-valor (Banco de Dados Primário): Tabelas Globais do DynamoDB ou Cassandra (multirregional) que armazenam short_code -> long_url e metadados como a fonte canônica da verdade. - Serviço de Alocação de ID (Alocador de Intervalo): um pequeno serviço que distribui blocos de ID para servidores da API de Gravação para geração local de códigos curtos (garante exclusividade sem bloqueio central por gravação). - API de Gravação: serviço que lida com solicitações de criação, reserva/gera o short_code (via bloco de ID), persiste no banco de dados primário e propaga uma invalidação para caches e CDN. As gravações são síncronas para o banco de dados primário para durabilidade. - Invalidação e propagação de cache: na criação/atualização/exclusão, a API de Gravação atualiza os caches regionais e invalida as entradas de borda da CDN via API de invalidação da CDN ou escrevendo cabeçalhos cache-control e usando um token de versão no URL, se necessário. - Pipeline de análise (assíncrono): eventos de redirecionamento são registrados de forma assíncrona (não no caminho de redirecionamento síncrono). Loggers de borda ou servidores de leitura regionais enviam eventos de clique leves para um barramento de mensagens (Kafka / Kinesis). O processamento de stream (Flink / Spark Streaming) agrega e grava em um armazenamento de análise (ClickHouse / BigQuery) e em contadores pré-agregados em um armazenamento otimizado para leitura para dashboards. - API e UI de Dashboard: lê análises agregadas de armazenamento OLAP/agregados e serve dashboards de usuário. Consultas de dashboard nunca atingem o caminho de redirecionamento. B. Estratégia de geração de URL Objetivos: exclusividade, compacidade (<=7 caracteres alfanuméricos), alta taxa de transferência, baixa contenção. Abordagem escolhida: IDs numéricos sequenciais alocados em blocos de ID distribuídos, codificados em base62 para produzir o código curto. - Por que IDs sequenciais base62: base62 (a–z, A–Z, 0–9) fornece 62^7 ≈ 3,52 × 10^12 códigos possíveis com strings de até 7 caracteres — muito mais do que as necessidades esperadas de vida útil. IDs sequenciais codificam de forma compacta e são fáceis de reverter para valores numéricos, se necessário. O mapeamento determinístico evita colisões de hash. - Implementação de alocação de ID: um alocador central distribui intervalos de ID monotonicamente crescentes (por exemplo, blocos de 1M) para cada cluster de servidor de gravação. Cada servidor de gravação emite IDs locais de seu bloco sem coordenação remota, garantindo exclusividade e latência muito baixa. O próprio alocador é pequeno e pode ser suportado por um armazenamento altamente disponível (RDS ou um contador leve baseado em ZooKeeper/etcd) e usado apenas para recargas de bloco (QPS baixo). - Codificação: ID numérico -> string base62. Se o ID numérico < 62^7, o comprimento da codificação é <=7. Com 100M de novos encurtamentos/mês (1,2B/ano), a capacidade de 62^7 fornece mais de 2.900 anos de espaço. - Tratamento de colisões: nenhuma esperada porque os IDs numéricos são exclusivos. Ainda assim, a API de Gravação usa uma inserção condicional contra o banco de dados primário (PUT com chave primária == short_code) e retenta em raras conflitos de banco de dados primário (não deve acontecer se o alocador estiver correto). Para aliases personalizados solicitados pelo usuário, verifique e retorne erro se já estiverem em uso. - Desduplicação opcional: opcionalmente, mantenha um índice de hash secundário (por exemplo, SHA-256 de long_url) para retornar um código curto existente se o mesmo URL foi encurtado anteriormente pelo mesmo usuário; este é um comportamento em nível de aplicativo e é opcional. C. Modelo de dados e armazenamento Escolhas de armazenamento de dados primário: Tabelas Globais do DynamoDB (gerenciado, multirregional, latência de leitura/gravação de um único dígito ms), ou Apache Cassandra / ScyllaDB (multirregional auto-gerenciado) como as escolhas canônicas. Recomendo Tabelas Globais do DynamoDB para operações mais rápidas e replicação multirregional mais simples, a menos que você precise ser agnóstico em relação à nuvem. Esquema da tabela de mapeamento primário (otimizado para chave-valor): - Nome da tabela: URL_Mapping - Chave primária: short_code (string, PK) - Atributos: long_url (texto), user_id (string), created_at (timestamp), custom_alias_flag (bool), deleted_flag (bool), metadata (JSON/Mapa esparso), analytics_enabled (bool), version (int) - Índices secundários (opcional): user_id -> lista de short_codes (GSI) para UI de gerenciamento; long_hash -> short_code (para desduplicação, se desejado) Estimativas de armazenamento: assuma que cada registro armazena 200 bytes em média (short_code ~7 bytes, URL avg 200? mas podemos comprimir; assuma 200–400 bytes conservador). Com 100M/mês de novas linhas: 100M * 200 B = 20 GB/mês. Anual ≈ 240 GB. Dez anos ≈ 2,4 TB. DynamoDB/Cassandra podem lidar facilmente com essa escala. Armazenamentos de análise: eventos de clique brutos vão para sistemas somente de adição (Kafka/Kinesis) e depois para um armazenamento de análise de longo prazo (ClickHouse ou BigQuery) para agregação e dashboards. Contadores pré-agregados (por short_code por bucket de tempo) podem ser armazenados no ClickHouse e contadores quentes em cache no Redis para consultas de dashboard. D. Otimização do caminho de leitura (atingindo <10 ms p99 redirects) O objetivo é servir redirecionamentos do 99º percentil em menos de 10 ms desde a chegada da solicitação até a emissão de 301/302. Técnicas usadas: 1) CDN + Cache de Borda (otimização primária): armazene em cache respostas 301 completas nas bordas da CDN para quase todas as solicitações. Defina TTLs muito longos (efetivamente não expirando) porque os mapeamentos não expiram, mas suporte invalidação imediata quando um mapeamento é atualizado/excluído. - Com acerto de borda da CDN, a latência para o cliente geralmente é <10 ms globalmente. 2) Função de borda muito pequena para consulta de cache miss: CloudFront Function ou o compute de borda do Fastly para minimizar a sobrecarga de tempo de execução (~sub-ms). Se houver cache miss, a função de borda chama uma API de Redirecionamento regional via uma conexão TCP curta (keepalive) e retorna 301 para a CDN. 3) Cache de leitura regional (Redis em cada região): O cache regional é um armazenamento com prioridade para memória para consultas de mapeamento; GET típico do Redis <1 ms. Meta de taxa de acerto do cache: >=99% para códigos quentes. Use descarte LFU/LRU e tamanho para manter o conjunto de trabalho. - Exemplo de dimensionamento de cache: assuma RPS global de pico = 40k leituras/segundo; conjunto de trabalho dos 50M principais códigos (cauda quente) — armazene pares short_code->long_url (média de 200 bytes). Memória = 50M * 200 B ≈ 10 GB. Um cluster Redis multishard modesto (por exemplo, 4-8 nós de 32 GB cada) por região pode lidar com isso. 4) Acesso ao banco de dados de origem apenas em cache miss: GetItem de linha única do DynamoDB geralmente é de poucos ms (1–10 ms), mas projetamos para evitar estar no caminho crítico para p99, armazenando em cache pesadamente. 5) Mantenha a função de borda + caminho HTTP mínimos: use HTTP/2 ou HTTP/3 entre a CDN e a origem para reduzir a latência de handshake e permitir a reutilização de conexão. 6) Roteamento Anycast local + ciente de geolocalização: envie o cliente para a borda/região mais próxima para manter o RTT baixo. Medição e SLA: teste com tráfego sintético e orçamentos de latência do 99º percentil alocados: acerto da CDN (meta <5 ms), função de borda + Redis <10 ms, fallback de origem aceitável para baixos percentis, mas será monitorado e ajustado. E. Caminho de gravação: criação e persistência 1) O cliente faz POST /create (ou via UI) para a API de Gravação (endpoint ciente da região). A camada da API de Gravação é sem estado e autoescalável. 2) A API de Gravação obtém um ID numérico de seu bloco de ID alocado localmente (alocador de intervalo). Se o bloco estiver esgotado, solicita um novo bloco do alocador. 3) Codifica o ID numérico para short_code base62. 4) Persiste no banco de dados primário com uma inserção condicional: PutItem(short_code, long_url, metadata) com expressão condicional de que short_code não existe (evita sobrescrita acidental de alias personalizado). Garante gravação atômica para durabilidade. 5) Após a gravação bem-sucedida: - Atualiza o cache de leitura regional (write-through) para que redirecionamentos subsequentes atinjam o cache. - Envia uma solicitação de pré-aquecimento de cache da CDN ou publica uma invalidação para este short_code na CDN para que o novo mapeamento seja imediatamente armazenado em cache nas bordas (ou aproveite o cache-control + versionamento da CDN para torná-lo eficaz). 6) Retorna o short_code criado para o usuário. Durabilidade e consistência: gravação síncrona no banco de dados primário com replicação entre regiões (Tabelas Globais do DynamoDB ou Cassandra com replicação multissede). Se usar DynamoDB, o modelo de consistência pode ser eventualmente consistente para leituras, mas as gravações são duráveis e replicadas. Números operacionais: QPS de gravação média ~40 gravações/segundo (100M/mês ≈ 38,6/s). Picos de rajadas são possíveis; o pipeline de gravação é fácil de escalar horizontalmente. F. Estratégia de escalonamento (escalonamento horizontal) - Servidores de API / Redirecionamento sem estado: escalam horizontalmente automaticamente atrás de um balanceador de carga global (ALB / GCLB). Mantenha os servidores sem estado para que sejam fáceis de escalar. - Alocador de ID: QPS baixo — escala tornando-o tolerante a falhas (ativo/passivo + contador persistido ou alocação de intervalo delegada). Aloque blocos maiores para reduzir a carga do alocador. - Caches: clusters Redis/ElastiCache por região, fragmentados (hashing consistente). Adicione fragmentos para aumentar a taxa de transferência de memória. - Banco de Dados Primário: autoescalonamento do DynamoDB ou cluster Cassandra que pode adicionar nós e aumentar a taxa de transferência. Escolha tamanhos de instância e fator de replicação para atender à capacidade de leitura/gravação. - Barramento de mensagens (Kafka/Kinesis): particione o fluxo de cliques por hash de short_code para escalar a ingestão. Use partições e brokers suficientes para atender à taxa de transferência de pico (por exemplo, se o pico de redirecionamentos for 38k RPS gerando 38k eventos/segundo, provisione partições e brokers Kafka para lidar com ~50–100k eventos/s com fator de replicação 3). - Computação de análise: escala clusters Flink / Spark horizontalmente com base no volume de eventos. - A CDN escala automaticamente; a configuração da CDN deve ser ajustada para as taxas de solicitação. G. Confiabilidade e tolerância a falhas Objetivos: sobreviver à queda de um data center inteiro, garantir nenhuma perda de dados. - Implantação multirregional: implante pelo menos duas regiões ativas (multi-ativas) com roteamento global. Use balanceamento de carga global + verificações de integridade para rotear em torno de regiões com falha. - Replicação do banco de dados primário: Tabelas Globais do DynamoDB fornecem replicação ativa-ativa entre regiões; Cassandra/Scylla podem ser configurados com fator de replicação entre data centers. Isso fornece durabilidade se um DC for perdido. - Caches regionais ficam aquecidos em caso de falha: quando uma região falha, o tráfego é roteado para a próxima região, que terá seu próprio cache. O front-end frio de uma região após failover pode causar mais leituras de origem até que os caches aqueçam, mas a disponibilidade é preservada. - Tolerância a falhas do alocador de ID: estado do alocador persistido em um armazenamento de alta disponibilidade; aloque blocos grandes para reduzir a necessidade de acessar o alocador em caso de falha. - Replicação do barramento de mensagens: Kafka com fator de replicação >=3 entre racks/regiões ou Kinesis gerenciado com replicação entre regiões para durabilidade. - Verificações de integridade e failover automatizado: monitoramento ativo, disjuntores, limitação de taxa para evitar sobrecarga durante o failover. - Backups: snapshots periódicos do banco de dados primário e exportações de metadados. Para DynamoDB, habilite recuperação point-in-time; para Cassandra, snapshots agendados. H. Pipeline de análise (coletar/processar/servir sem impactar redirecionamentos) Princípio de design: as gravações de análise devem ser assíncronas e nunca bloquear redirecionamentos. 1) Geração leve de eventos: a borda (CDN/função de borda) emite um pequeno evento para cada redirecionamento (short_code, timestamp, client_ip ou tag geo, referrer, user-agent). Para minimizar a latência de redirecionamento, a emissão é feita via um push muito rápido semelhante a UDP para um proxy local ou via agregação em memória no servidor de leitura e enviado assincronamente. 2) Barramento de mensagens: eventos são enviados para tópicos Kafka ou Kinesis particionados por short_code (ou hash) para suportar processamento paralelo escalável. O produtor deve ser assíncrono e não bloqueante; se o buffer Kafka local estiver cheio, recorra à amostragem ou descarte campos de baixo valor para garantir que a latência de redirecionamento não seja afetada. Os produtores usam buffer local e políticas de backpressure. 3) Processamento de stream: Flink / Kafka Streams / Spark Streaming consome eventos, enriquece (consulta geo-IP, análise de UA) e calcula agregações em tempo real (contagens de cliques, distribuição geográfica, referrers) em granularidade de minuto/hora. Pré-agrega por short_code por janela de tempo. 4) Armazenamento OLAP e agregados: grava dados agregados no ClickHouse ou BigQuery para consultas analíticas rápidas e armazenamento de longo prazo. Para servir dashboards, armazene agregados recentes em um armazenamento de leitura rápida (Redis ou Druid) para consultas interativas. 5) API de Dashboard: lê apenas de armazenamento de agregados/OLAP; nenhuma consulta direta do armazenamento de análise para o caminho de redirecionamento. Implemente limites de taxa e cotas por usuário para consultas de dashboard. 6) Amostragem e logging em camadas: para short_codes de tráfego extremamente alto, opcionalmente amostre eventos para reduzir a carga do pipeline, preservando análises representativas. Exemplo de desempenho: pico de redirecionamentos ~40k/s -> eventos 40k/s -> ingestão Kafka facilmente gerenciável com 100 partições e alguns brokers. Processadores de stream escalam horizontalmente para lidar com esse volume e gravam agregados resumidos a cada minuto no ClickHouse. I. Principais trade-offs (pelo menos três) com justificativa 1) Cache de borda da CDN vs consistência imediata para exclusões/atualizações - Trade-off: Usar cache de borda da CDN de longa duração oferece latência de redirecionamento muito baixa, mas torna a propagação de atualização/exclusão um pouco mais complexa e não instantânea em todos os lugares. - Justificativa: O SLA de latência de redirecionamento é rigoroso (<10 ms p99). Operações típicas para modificar/excluir um URL curto são raras em comparação com redirecionamentos. Preferimos latência ultrabaixa para redirecionamentos e aceitamos invalidação de cache ligeiramente atrasada (fornecemos APIs de invalidação imediatas para casos importantes). Também incluímos um token de versão ou estratégia de invalidação de TTL curto para atualizações críticas. 2) Alocação de ID sequencial (blocos de intervalo + base62) vs esquema totalmente aleatório/de hash - Trade-off: A alocação sequencial com blocos requer um pequeno serviço alocador e manuseio cuidadoso durante o failover entre regiões, enquanto a geração de hash/aleatória pode ser totalmente sem estado, mas requer resolução de colisão ou um comprimento de código maior para reduzir colisões. - Justificativa: IDs sequenciais produzem códigos compactos e muito curtos de forma determinística e evitam o tratamento de colisões no momento da gravação. Com a alocação de blocos, a carga do alocador é mínima e escalável. Dada a chave de espaço extremamente grande (62^7), não precisamos de aleatoriedade para evitar colisões. 3) DynamoDB (gerenciado, multirregional) vs Cassandra auto-hospedado - Trade-off: O DynamoDB simplifica o fardo operacional e oferece replicação multirregional gerenciada, mas pode ser mais caro e um pouco menos flexível em padrões de consulta em comparação com Cassandra/Scylla auto-hospedado. - Justificativa: O padrão de acesso do sistema é leitura/gravação simples de chave primária; valorizamos a simplicidade operacional, confiabilidade e escalonamento automático e, portanto, recomendamos Tabelas Globais do DynamoDB, a menos que restrições de custo forcem Cassandra. 4) Caching write-through síncrono vs propagação eventual para caches - Trade-off: O write-through síncrono para caches aumenta ligeiramente a latência de gravação, mas garante disponibilidade imediata nos caches de leitura; a propagação eventual reduz a latência de gravação, mas pode causar uma janela curta onde os redirecionamentos falham. - Justificativa: As gravações têm QPS baixo (≈40/s), portanto, realizar uma gravação em cache na criação é aceitável para garantir que os links recém-criados estejam imediatamente disponíveis para redirecionamentos e evitar cache misses frios para códigos curtos recém-criados. Considerações operacionais e telemetria - Monitoramento: latência de redirecionamento p99, taxa de acerto do cache, RPS de origem, latência de gravação, atraso do barramento de mensagens, atraso do pipeline de análise. Alertas para atraso de replicação entre DCs. - Planejamento de capacidade: planeje com 10x de segurança de pico. Números de exemplo: - QPS de leitura (média): 3.858 RPS = 10B/mês. Suposição de pico 10x => ~38,6k RPS. - Meta de acerto de borda da CDN: 99% → RPS de origem ≈ 386 RPS. Caches regionais dimensionados para manter o conjunto de trabalho quente. - Dimensionamento de cache: para manter as 50M principais chaves a 200 B cada → 10 GB; use múltiplos fragmentos por região. - Taxa de transferência do Kafka: no pico de 40k eventos/s, com tamanho médio de evento de 500 B => ~20 MB/s de ingestão; com fator de replicação 3 e sobrecarga, planeje ~60 MB/s de taxa de transferência do cluster. - Taxa de transferência do banco de dados primário: gravações ~40/s, leituras da origem após cache misses ~386/s agregadas (ou divisões por região). O autoescalonamento de capacidade do DynamoDB suporta facilmente esses níveis. Recursos de segurança e operacionais - Limitação de taxa e detecção de abuso na borda para mitigar spam ou bots. - Limitação de gravação de análise durante sobrecarga, amostragem para códigos extremamente quentes. - Controles de acesso (tokens OAuth/API) para criar e gerenciar URLs curtos. - Logs de auditoria para exclusões para atender à garantia de não expiração, a menos que explicitamente excluídos. Conclusão Este projeto prioriza a latência de redirecionamento e a disponibilidade via cache de borda da CDN + lógica de borda mínima, armazenamento multirregional durável para mapeamentos permanentes, um esquema de alocação de ID e codificação base62 simples e robusto (garantindo nenhuma colisão e <=7 caracteres), e um pipeline de análise completamente assíncrono para que as análises nunca degradem o desempenho do redirecionamento. A arquitetura escala horizontalmente, sobrevive a interrupções completas de DC via replicação multirregional e fornece alavancas operacionais (dimensionamento de cache, invalidação de CDN, amostragem) para equilibrar custos versus desempenho.