Projetar um Serviço Global de Encurtamento de URLs

1. Arquitetura de alto nível com componentes principais e fluxo de dados: * **Usuário/Cliente:** Interage com o serviço. * **API Gateway/Balanceador de Carga:** Ponto de entrada para todas as requisições, lida com roteamento, limitação de taxa e terminação SSL. * **Serviço de Encurtamento:** Microsserviço responsável pela criação, atualização e gerenciamento de URLs curtas. Interage com o Banco de Dados de Metadados de Links e o Cache. * **Serviço de Redirecionamento:** Microsserviço otimizado para redirecionamentos de alta vazão e baixa latência. Lê principalmente do Cache, com fallback para o Banco de Dados de Metadados de Links. Publica eventos de clique em uma Fila de Mensagens. * **Cache Distribuído (ex: Cluster Redis):** Armazena mapeamentos de `short_code` para `long_url` quentes para redirecionamentos rápidos. * **Banco de Dados de Metadados de Links (ex: Cassandra/DynamoDB):** Armazena todos os metadados de URLs curtas (`short_code`, `long_url`, expiração, status, etc.). * **Fila de Mensagens (ex: Kafka/Kinesis):** Ingesta eventos de clique brutos do Serviço de Redirecionamento para processamento assíncrono. * **Processador de Análise:** Consome eventos de clique brutos da Fila de Mensagens, realiza agregação e os armazena no Banco de Dados de Análise. * **Banco de Dados de Análise (ex: ClickHouse/Redshift):** Armazena dados de clique agregados para consulta. * **Data Lake (ex: S3):** Armazena eventos de clique brutos para retenção de longo prazo e análise mais profunda. * **Serviço de Detecção de Abuso:** Integra-se ao Serviço de Encurtamento para verificar novas URLs em busca de conteúdo malicioso. * **Monitoramento e Alerta:** Observabilidade para todos os componentes. **Fluxo de Dados:** * **Requisição de Encurtamento:** Usuário -> API Gateway -> Serviço de Encurtamento -> Detecção de Abuso -> Banco de Dados de Metadados de Links (escrita) -> Cache (escrita). * **Requisição de Redirecionamento:** Usuário -> CDN (opcional) -> Balanceador de Carga -> Serviço de Redirecionamento -> Cache (leitura) -> Banco de Dados de Metadados de Links (leitura de fallback) -> Fila de Mensagens (escrita de evento de clique) -> Redirecionamento para URL Longa. * **Processamento de Análise:** Fila de Mensagens -> Processador de Análise -> Banco de Dados de Análise (escrita agregada) / Data Lake (escrita bruta). 2. Escolhas de armazenamento para metadados de links, caminho de redirecionamento e eventos de análise, com justificativa: * **Metadados de Links (URL Curta -> URL Longa, Expiração, Status, etc.):** * **Escolha:** Banco de dados NoSQL distribuído globalmente (ex: Apache Cassandra ou AWS DynamoDB Global Tables). * **Justificativa:** Lida com alta vazão de leitura/escrita (1,5 bilhão de leituras/dia, 120 milhões de escritas/mês), oferece acesso de baixa latência de várias regiões, fornece alta disponibilidade e escala horizontalmente. A chave primária seria o `short_code` para consultas eficientes. * **Caminho de Redirecionamento (Mapeamento de Código Curto -> URL Longa para consulta rápida):** * **Escolha:** Cache distribuído em memória (ex: Cluster Redis). * **Justificativa:** Crucial para atingir p95 de latência abaixo de 80ms para redirecionamentos. Reduz significativamente a carga no banco de dados principal. Links quentes são cacheados agressivamente com TTLs apropriados (ex: com base na expiração do link ou política LRU). Replicado entre regiões para acesso local. * **Eventos de Análise (Cliques Brutos):** * **Escolha:** Fila de Mensagens (ex: Apache Kafka ou AWS Kinesis) para ingestão, seguida por um Data Lake (ex: AWS S3) para armazenamento. * **Justificativa:** Kafka/Kinesis lida com o imenso volume de escrita (1,5 bilhão de eventos/dia) ao desacoplar o caminho de redirecionamento do processamento de análise, garantindo que os redirecionamentos permaneçam rápidos. S3 fornece armazenamento econômico e altamente durável para eventos brutos retidos por 90 dias, adequado para processamento em lote e análise histórica. * **Análise Agregada:** * **Escolha:** Banco de dados analítico colunar (ex: ClickHouse ou AWS Redshift). * **Justificativa:** Otimizado para consultas analíticas complexas e agregações sobre grandes conjuntos de dados. Permite consulta rápida de dados agregados (ex: cliques diários, distribuição de navegadores) em até 15 minutos, retidos por 2 anos, sem impactar o banco de dados operacional. 3. Estratégia de geração de short-code, incluindo como evitar colisões e lidar com aliases personalizados: * **Estratégia de Geração de Short-code:** 1. **Geração de ID Distribuído:** Use um gerador de ID distribuído e exclusivo (ex: um serviço personalizado gerando IDs semelhantes ao Snowflake ou UUID v7) para produzir um ID inteiro de 64 bits globalmente exclusivo e monotonicamente crescente. 2. **Codificação Base62:** Codifique este ID inteiro exclusivo em uma string compacta Base62 (0-9, a-z, A-Z). Um ID de 64 bits pode produzir um código curto de 6 a 10 caracteres, oferecendo um vasto namespace (ex: 6 caracteres fornecem 62^6 ≈ 56 bilhões de códigos exclusivos, suficientes para 120 milhões/mês por muitos anos). * **Evitar Colisões:** * **Baseado em ID:** Como o ID subjacente é garantidamente exclusivo, o short code codificado em Base62 também será exclusivo, evitando inerentemente colisões para códigos gerados pelo sistema. * **Fallback Aleatório (para robustez):** Como uma opção secundária ou para casos de uso específicos, um gerador de string aleatória pode ser usado. Nesse caso, gere um short code candidato, em seguida, realize uma consulta rápida no Banco de Dados de Metadados de Links e no Cache. Se uma colisão for detectada, regenere e tente algumas vezes. Isso é menos eficiente, mas fornece um fallback. * **Aliases Personalizados:** 1. **Submissão do Usuário:** Os usuários enviam seu `custom_alias` desejado junto com o `long_url`. 2. **Validação:** O Serviço de Encurtamento valida o `custom_alias` (ex: comprimento, caracteres permitidos, não é uma palavra reservada, não está em lista negra). 3. **Verificação de Exclusividade:** Antes da criação, o Serviço de Encurtamento realiza uma consulta no Banco de Dados de Metadados de Links para verificar se o `custom_alias` já existe. Essa verificação deve ser fortemente consistente. 4. **Reserva:** Se o `custom_alias` estiver disponível, ele é armazenado diretamente como o `short_code` no Banco de Dados de Metadados de Links. Se indisponível, a requisição é rejeitada, solicitando ao usuário que escolha outro. 4. Plano de escalabilidade para tráfego global, incluindo cache, particionamento/sharding e considerações multirregionais: * **Cache:** * **CDN:** Utilize uma Rede de Distribuição de Conteúdo (CDN) para ativos estáticos e potencialmente para resolução DNS de links curtos, direcionando os usuários para o local de borda mais próximo. * **Cache Distribuído (Cluster Redis):** Implante clusters Redis em cada região geográfica principal. Esses clusters armazenarão os mapeamentos `short_code` para `long_url` mais acessados. As entradas de cache têm TTLs alinhados com a expiração do link ou política LRU. Isso descarrega significativamente o banco de dados para os 1,5 bilhão de redirecionamentos diários. * **Particionamento/Sharding:** * **Banco de Dados de Metadados de Links:** Particione o banco de dados pelo `short_code` (ex: usando um hash do short code). Isso distribui os dados e a carga de consulta entre vários nós de banco de dados. Cada partição é replicada para alta disponibilidade dentro de uma região. * **Banco de Dados de Análise:** Particione eventos de clique brutos por tempo (ex: partições diárias ou horárias) e dados agregados por `short_code` e `date` para otimizar o desempenho da consulta e as políticas de retenção de dados. * **Considerações Multirregionais:** * **Ativo-Ativo para Redirecionamentos:** Implante o Serviço de Redirecionamento, o Cache Distribuído e o Banco de Dados de Metadados de Links (com replicação global) em várias regiões geográficas (ex: América do Norte, Europa, Ásia-Pacífico). Geo-DNS roteia os usuários para a região mais próxima, garantindo redirecionamentos de baixa latência globalmente. * **Ativo-Passivo/Ativo-Ativo para Serviço de Encurtamento:** O Serviço de Encurtamento pode ser implantado ativo-passivo (primário em uma região, réplicas em outras) ou ativo-ativo, dependendo dos requisitos de consistência de escrita e complexidade. As escritas são menos frequentes que as leituras, portanto, uma latência ligeiramente maior para criação é aceitável se simplificar a consistência. * **Replicação Global de Banco de Dados:** O Banco de Dados de Metadados de Links (ex: Tabelas Globais do DynamoDB ou replicação de múltiplos data centers do Cassandra) garante que os dados sejam replicados entre regiões, permitindo leituras locais para redirecionamentos e fornecendo recursos de recuperação de desastres. * **Ingestão de Análise:** Filas de Mensagens Regionais (Kafka/Kinesis) agregam eventos de clique localmente, que são então transmitidos para um Data Lake/Banco de Dados de Análise central ou replicados entre regiões para análise consolidada. 5. Plano de confiabilidade cobrindo falhas, chaves quentes, recuperação de desastres e comportamento em modo degradado: * **Falhas:** * **Redundância:** Todos os serviços (Encurtamento, Redirecionamento, Processadores de Análise) são implantados com redundância N+1 em múltiplas zonas de disponibilidade dentro de cada região, atrás de balanceadores de carga. * **Replicação de Banco de Dados:** O Banco de Dados de Metadados de Links e o Banco de Dados de Análise usam replicação síncrona/assíncrona entre zonas de disponibilidade e regiões para garantir durabilidade e disponibilidade dos dados. * **Circuit Breakers e Retentativas:** Implemente circuit breakers e mecanismos de backoff exponencial/retentativa em microsserviços para evitar falhas em cascata e lidar com problemas transitórios graciosamente. * **Monitoramento e Alerta:** Monitoramento abrangente da saúde do sistema, métricas de desempenho e taxas de erro com alertas automatizados para problemas críticos. * **Chaves Quentes:** * **Sharding de Cache:** O Cache Distribuído (Cluster Redis) é particionado, distribuindo chaves quentes entre vários nós para evitar que um único nó se torne um gargalo. * **Aquecimento de Cache:** Para links quentes antecipados (ex: de grandes campanhas), pré-carregue-os no cache. * **Limitação de Taxa:** Implemente limitação de taxa no nível do API Gateway e do Serviço de Redirecionamento para proteger os sistemas de backend de picos repentinos de tráfego ou abuso direcionado a links específicos. * **Recuperação de Desastres:** * **Ativo-Ativo Multirregional:** A implantação ativo-ativo para o Serviço de Redirecionamento e o Banco de Dados de Metadados de Links globalmente replicado fornece recuperação de desastres inerente para redirecionamentos. Se uma região falhar, o tráfego é automaticamente roteado para outra região saudável via Geo-DNS. * **Backups de Dados:** Backups regulares e automatizados de todos os bancos de dados críticos (Metadados de Links, Análise Agregada) para armazenamento durável geograficamente separado (ex: S3). * **Playbooks de Recuperação:** Procedimentos documentados e regularmente testados para failover, restauração de dados e recuperação completa do sistema. * **Comportamento em Modo Degradado:** * **Degradação de Análise:** Se a Fila de Mensagens ou o Processador de Análise apresentar problemas, os eventos de clique brutos podem ser temporariamente armazenados em buffer ou, em casos extremos, descartados (com alertas). Os redirecionamentos devem continuar a funcionar sem interrupção. * **Falha/Misses de Cache:** Se o Cache Distribuído falhar ou apresentar alta latência, o Serviço de Redirecionamento recorrerá à consulta do Banco de Dados de Metadados de Links. Isso resultará em maior latência de redirecionamento, mas garantirá a continuidade do serviço. Circuit breakers impedem sobrecarregar o banco de dados. * **Degradação do Serviço de Encurtamento:** Se o Serviço de Encurtamento estiver prejudicado, os redirecionamentos não serão afetados. Os usuários podem experimentar criação de links mais lenta ou indisponibilidade temporária da API de criação, mas os links existentes continuarão a funcionar. 6. Principais APIs e modelos de dados principais: * **Principais APIs:** * **`POST /api/v1/shorten`** * **Descrição:** Cria uma nova URL curta. * **Corpo da Requisição:** `{"long_url": "string", "custom_alias": "string (opcional)", "expiration_date": "timestamp ISO 8601 (opcional)", "user_id": "string (opcional)"}` * **Resposta:** `{"short_url": "string", "long_url": "string", "expires_at": "timestamp ISO 8601 (opcional)"}` * **`GET /{short_code}`** * **Descrição:** Redireciona para a URL longa original. * **Resposta:** Redirecionamento HTTP 301/302 para `long_url`. * **`GET /api/v1/links/{short_code}/analytics`** * **Descrição:** Recupera a análise de cliques para uma URL curta específica. * **Resposta:** `{"short_code": "string", "total_clicks": "integer", "daily_clicks": [{"date": "YYYY-MM-DD", "count": "integer"}], "browser_distribution": {"Chrome": 100, "Firefox": 50}, "country_distribution": {"US": 70, "DE": 30}}` * **`PUT /api/v1/links/{short_code}/status`** * **Descrição:** Atualiza o status de uma URL curta (ex: desativar). * **Corpo da Requisição:** `{"status": "enum (active, disabled)"}` * **Resposta:** `{"short_code": "string", "status": "string"}` * **Modelos de Dados Principais:** * **Metadados de Links (Armazenado no Banco de Dados de Metadados de Links):** ``` { "short_code": "string (Chave Primária)", "long_url": "string", "user_id": "string (Chave Estrangeira, opcional)", "created_at": "timestamp", "expires_at": "timestamp (opcional)", "status": "enum (active, disabled, expired)", "is_custom_alias": "boolean", "last_accessed_at": "timestamp (para LRU/limpeza)" } ``` * **Evento de Clique (Bruto - Armazenado no Data Lake, ingerido via Fila de Mensagens):** ``` { "event_id": "UUID (Chave Primária)", "short_code": "string", "timestamp": "timestamp", "ip_address_hash": "string (anonimizado/hash)", "user_agent": "string", "referrer": "string (opcional)", "country": "string (derivado do IP)", "city": "string (derivado do IP)" } ``` * **Análise Agregada (Armazenada no Banco de Dados de Análise):** ``` { "short_code": "string (Chave de Partição)", "date": "date (Chave de Classificação)", "total_clicks": "integer", "browser_counts": "map<string, integer>", "os_counts": "map<string, integer>", "country_counts": "map<string, integer>", "referrer_counts": "map<string, integer>" } ``` 7. Considerações sobre mitigação de abusos e segurança: * **Detecção de Links Maliciosos:** * **Lista Negra:** Mantenha uma lista negra continuamente atualizada de domínios, sites de phishing e URLs de spam conhecidos. Novas submissões de `long_url` são verificadas contra essa lista. * **Verificação em Tempo Real:** Integre-se a APIs de navegação segura de terceiros (ex: Google Safe Browsing API, VirusTotal) durante o processo de criação de links para verificar a `long_url` em busca de ameaças conhecidas. * **Heurísticas:** Implemente algoritmos para detectar padrões de URL suspeitos, redirecionamentos excessivos ou palavras-chave comumente associadas a abusos. * **Prevenção de Spam e Abuso:** * **Limitação de Taxa:** Aplique limites de taxa rigorosos na API `POST /shorten` por endereço IP e/ou usuário autenticado para evitar spam automatizado. * **CAPTCHA/reCAPTCHA:** Para criação de links anônimos, implemente desafios CAPTCHA para impedir bots. * **Contas de Usuário:** Exija autenticação de usuário para aliases personalizados, limites de criação mais altos e acesso a análises. Isso fornece responsabilidade. * **Mecanismo de Denúncia:** Forneça uma maneira clara para os usuários denunciarem links curtos abusivos. Links denunciados são revisados e desativados se considerados maliciosos. * **Desativação de Links:** Permita que os usuários desativem seus próprios links. O sistema também pode desativar automaticamente links sinalizados pela detecção de abuso ou denunciados por outros. * **Considerações de Segurança:** * **HTTPS em Tudo:** Force HTTPS para todos os endpoints de API e redirecionamentos para garantir a criptografia de dados em trânsito. * **Validação e Sanitização de Entrada:** Valide e sanitize rigorosamente todas as entradas fornecidas pelo usuário (`long_url`, `custom_alias`) para evitar vulnerabilidades web comuns como XSS, injeção de SQL e traversal de diretório. * **Controle de Acesso:** Implemente controle de acesso baseado em função (RBAC) para ferramentas de gerenciamento internas e recursos de gerenciamento de links específicos do usuário. * **Anonimização de Dados:** Anonimize ou aplique hash em endereços IP e outras informações pessoalmente identificáveis (PII) nos dados de análise de cliques para cumprir regulamentações de privacidade (ex: GDPR, CCPA). * **Auditorias de Segurança Regulares:** Realize auditorias de segurança periódicas, testes de penetração e varreduras de vulnerabilidade para identificar e remediar possíveis fraquezas. * **Proteção DDoS:** Utilize serviços de mitigação DDoS do provedor de nuvem (ex: AWS Shield, Cloudflare) na borda. 8. As principais compensações que você fez e por quê: * **Consistência vs. Disponibilidade/Latência para Redirecionamentos:** * **Compensação:** Priorizou disponibilidade e baixa latência extremas para redirecionamentos em detrimento da forte consistência para metadados de links. Embora a criação de links exija forte consistência para exclusividade de alias, um link recém-criado ou atualizado pode levar alguns milissegundos para se propagar para todos os caches e réplicas de banco de dados globalmente antes de estar consistentemente disponível para redirecionamentos. * **Por quê:** Redirecionamentos são a operação mais crítica e de maior volume. Um pequeno atraso na disponibilidade global de um novo link ser redirecionável é aceitável, enquanto qualquer latência significativa ou tempo de inatividade para redirecionamentos impactaria severamente a experiência do usuário e as metas de confiabilidade do serviço. * **Custo vs. Desempenho/Escalabilidade:** * **Compensação:** Optou por uma arquitetura multirregional e globalmente replicada com cache extensivo e bancos de dados especializados, o que inerentemente incorre em custos de infraestrutura mais altos em comparação com uma configuração mais simples de região única. * **Por quê:** As suposições de escala (1,5 bilhão de redirecionamentos/dia, distribuição global) e as metas de desempenho (p95 < 80ms) exigem esse nível de infraestrutura distribuída. Serviços de nuvem de commodities e componentes de código aberto (como Kafka, Redis) foram escolhidos sempre que possível para otimizar o custo, ao mesmo tempo em que atendem aos requisitos de desempenho e escalabilidade. * **Granularidade de Dados vs. Custo de Armazenamento/Desempenho de Consulta para Análise:** * **Compensação:** Retém eventos de clique brutos por um período mais curto (90 dias) em um data lake econômico e armazena dados agregados por um período mais longo (2 anos) em um banco de dados analítico mais performático, mas potencialmente mais caro. * **Por quê:** Armazenar 1,5 bilhão de eventos brutos diariamente por 2 anos seria proibitivamente caro e lento para consultas em tempo real. Essa abordagem equilibra a necessidade de análise histórica detalhada (via dados brutos no S3) com o requisito de insights agregados rápidos (via banco de dados de análise) dentro das restrições orçamentárias. * **Comprimento do Código Curto vs. Probabilidade de Colisão/Adivinhação:** * **Compensação:** Escolheu a codificação Base62 para códigos curtos compactos (ex: 6-10 caracteres). Embora um código puramente aleatório de 6 caracteres tenha um risco teórico de colisão, a estratégia de geração baseada em ID elimina isso para códigos gerados pelo sistema. Para aliases personalizados, a detecção de colisão é explícita. * **Por quê:** A compacidade é uma característica central de um encurtador de URL. A estratégia escolhida fornece um namespace vasto o suficiente para evitar colisões práticas para códigos gerados pelo sistema e lida com colisões de alias personalizados graciosamente, sem exigir códigos curtos excessivamente longos ou complexos que prejudicariam o propósito de encurtar. * **Complexidade vs. Conjunto de Recursos:** * **Compensação:** Focou em um sistema central robusto para encurtamento, redirecionamento e análise básica, aceitando que recursos mais avançados (ex: testes A/B, gerenciamento complexo de usuários, relatórios complexos) seriam adições iterativas. * **Por quê:** Para atender às metas agressivas de desempenho e disponibilidade para a funcionalidade principal dentro de um escopo de design razoável. Adicionar muitos recursos inicialmente aumentaria a complexidade, os pontos de falha potenciais e o tempo de desenvolvimento, potencialmente comprometendo a estabilidade do serviço principal.

DESIGN: SERVIÇO GLOBAL DE ENCURTAMENTO DE URL ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1. ARQUITETURA DE ALTO NÍVEL E FLUXO DE DADOS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ COMPONENTES [Cliente] │ ▼ [DNS Anycast Global / GeoDNS] │ ▼ [PoPs de Borda Regionais — CDN / proxy reverso Nginx] │ (cache hit → resposta imediata 301/302) │ (cache miss → encaminhar para a origem) ▼ [Gateway de API Regional (limitação de taxa, autenticação, terminação TLS)] │ ├──► [Serviço de Redirecionamento] ──► [Cluster Redis (cache de chaves quentes)] │ │ miss │ ▼ │ [Armazenamento de Metadados de Link (Cassandra)] │ └──► [Serviço de Criação] ──► [Gerador de ID (estilo Snowflake)] │ │ ├──► [Armazenamento de Metadados de Link (Cassandra)] └──► [Verificador de Alias Personalizado (Redis SET + Cassandra)] [Serviço de Redirecionamento] ──► [Publicador de Eventos de Clique (Kafka)] │ ▼ [Processador de Fluxo (Flink / Spark Streaming)] │ ┌───────────┴────────────┐ ▼ ▼ [Armazenamento de Eventos Brutos [Armazenamento de Análises (S3 + Parquet, 90d)] Agregadas (ClickHouse, 2a)] FLUXO DE DADOS — REDIRECIONAMENTO (CAMINHO CRÍTICO) 1. Usuário visita https://sho.rt/aB3xYz 2. GeoDNS roteia para o PoP regional mais próximo. 3. CDN de Borda verifica seu cache local para a chave "aB3xYz". - HIT: retorna HTTP 301 (cacheável) ou 302 (não cacheável para análise) imediatamente. Dispara beacon assíncrono para o pipeline de análise. - MISS: encaminha para o Serviço de Redirecionamento regional. 4. Serviço de Redirecionamento verifica o cluster Redis regional. - HIT: retorna o URL de destino, dispara evento Kafka, responde 302. - MISS: lê de Cassandra (réplica mais próxima), popula Redis, responde 302. 5. Consumidor Kafka (Flink) processa o evento de clique em segundos; agregações chegam ao ClickHouse em ~5 minutos; pior caso 15 minutos. FLUXO DE DADOS — CRIAÇÃO 1. Cliente envia POST para o Serviço de Criação via Gateway de API. 2. Verificações de limite de taxa e autenticação aplicadas. 3. Se alias personalizado: verifica Redis SET e Cassandra para colisão; rejeita se ocupado. 4. Se gerado automaticamente: ID Snowflake → codificação Base62 → código de 7 caracteres. 5. Grava em Cassandra (gravação de quorum, RF=3). 6. Opcionalmente aquece o cache Redis imediatamente. 7. Retorna URL curto para o cliente. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2. ESCOLHAS DE ARMAZENAMENTO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ARMAZENAMENTO DE METADADOS DE LINK — Apache Cassandra Justificativa: - 120M de novos links/mês ≈ 46 links/segundo em média, com picos de 10–20×. Cassandra lida com alta taxa de transferência de gravação com consistência ajustável. - Padrão de acesso principal é consulta de chave única por short_code — o modelo de chave de partição do Cassandra é ideal. - Replicação multi-datacenter (RF=3 por região, 3 regiões) oferece disponibilidade de 99,99%+ sem um único ponto de falha. - Escala horizontalmente; nenhuma transação entre shards cara necessária. - Suporte TTL é nativo — links expirados são automaticamente marcados como tombstone. - Custo: nós commodity, sem taxas de licenciamento. Esquema (simplificado): Tabela: links short_code TEXT CHAVE PRIMÁRIA long_url TEXT owner_id UUID created_at TIMESTAMP expires_at TIMESTAMP (nulo; TTL do Cassandra definido na linha) is_disabled BOOLEAN is_custom BOOLEAN Alternativa considerada: DynamoDB — bom, mas vendor lock-in e custo nessa escala; PostgreSQL — não escalável horizontalmente para este volume de gravação sem complexidade significativa de sharding. CACHE DE CAMINHO DE REDIRECIONAMENTO — Cluster Redis (por região) - Armazena short_code → {long_url, is_disabled, expires_at} como um hash. - TTL na entrada do cache = min(expiração do link, 24 horas) para evitar entradas desatualizadas. - Modo cluster com 6 nós (3 primários + 3 réplicas) por região; ~50 GB de RAM por região cobre o conjunto de trabalho quente (top ~10M links). - Política de evicção: allkeys-lru. - Custo justificado: taxa de acerto do Redis esperada >95%; cada falha de cache custa uma leitura do Cassandra (~5–10 ms) mais latência; a 17.000 redirecionamentos/segundo por região, evitar leituras do Cassandra é crítico para a meta de p95. ANÁLISE — EVENTOS BRUTOS: Apache Kafka + S3 (Parquet) - Kafka (cluster de 3 brokers por região, tópico: click_events, 64 partições) armazena eventos de clique de forma durável. - Consumidores Flink leem do Kafka, enriquecem eventos (geo-IP, análise de user-agent) e gravam arquivos Parquet no S3 a cada 5 minutos. - Política de ciclo de vida do S3 exclui arquivos brutos após 90 dias. - Custo: S3 é barato (~$0,023/GB/mês); 1,5 bilhão de eventos/dia × ~200 bytes ≈ 300 GB/dia → ~27 TB/90 dias → ~$620/mês de armazenamento. ANÁLISE — AGREGADO: ClickHouse - Flink também grava linhas pré-agregadas (por short_code, por hora, por país/dispositivo) no ClickHouse. - O armazenamento colunar e a execução vetorizada do ClickHouse tornam as consultas de agregação de séries temporais rápidas. - Fator de replicação 2 por região; retenção de 2 anos. - Tamanho estimado: ~1 TB/ano agregado → muito gerenciável. - Alternativa considerada: Apache Druid — também excelente, mas operacionalmente mais pesado; ClickHouse é mais simples para este caso de uso. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3. ESTRATÉGIA DE GERAÇÃO DE CÓDIGO CURTO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CÓDIGOS GERADOS AUTOMATICAMENTE Estratégia: ID distribuído estilo Snowflake → Codificação Base62 1. Cada instância do Serviço de Criação mantém um ID de worker exclusivo (atribuído na inicialização via ZooKeeper ou uma tabela simples de banco de dados). 2. Gera um ID Snowflake de 64 bits: [timestamp de 41 bits ms | ID de worker de 10 bits | sequência de 12 bits]. 3. Codifica o ID em Base62 (caracteres: 0-9, a-z, A-Z). 4. Um inteiro de 64 bits codifica em no máximo 11 caracteres Base62; na prática, para IDs gerados nos primeiros ~10 anos, 7–8 caracteres são suficientes. 5. 7 caracteres em Base62 = 62^7 ≈ 3,5 trilhões de combinações — excede em muito 120M/mês × 12 meses × 10 anos = ~14,4 bilhões de links. Evitação de colisão: - IDs Snowflake são globalmente exclusivos por construção (ID de worker + timestamp + sequência). Nenhuma colisão é possível, a menos que dois workers compartilhem o mesmo ID de worker, o que é evitado pelo serviço de coordenação. - Não há necessidade de um loop "verificar e inserir" para códigos gerados automaticamente. Adivinhabilidade: - IDs Snowflake sequenciais codificados em Base62 não são aleatórios, mas também não são trivialmente enumeráveis (o componente de timestamp muda a cada milissegundo, a sequência é reiniciada). Para maior obscuridade, faça XOR dos 32 bits inferiores com um segredo por implantação antes de codificar. Isso não é segurança criptográfica, mas aumenta a barreira para ataques de enumeração. - Se for necessária maior imprevisibilidade: gere 6 bytes aleatórios → Base62 → código de 8 caracteres; verifique Cassandra para colisão (rara nessa escala); tente novamente em caso de colisão. Taxa de colisão esperada em 1,4 bilhão de links existentes de um espaço de 62^8 ≈ 218T é insignificante (<0,001%). ALIASES PERSONALIZADOS 1. Usuário fornece o alias desejado (por exemplo, "minha-promo-2025"). 2. Valida: 3–50 caracteres, alfanuméricos + hifens, sem palavras reservadas (api, admin, health, etc.). 3. Verifica Redis SET "custom_aliases" para existência (verificação semelhante a filtro de bloom O(1), ou um Redis SET). 4. Tenta Cassandra INSERT IF NOT EXISTS (transação leve / compare-and-set). 5. Se já estiver ocupado, retorna HTTP 409 Conflict. 6. Aliases personalizados são armazenados com is_custom=true; eles nunca são substituídos pelo caminho de geração automática. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4. PLANO DE ESCALA PARA TRÁFEGO GLOBAL ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ MATEMÁTICA DO TRÁFEGO - 1,5 bilhão de redirecionamentos/dia = ~17.400 req/segundo em média; assuma 3× pico = ~52.000 req/segundo. - 120M de criações/mês = ~46/segundo em média; 10× pico = ~460/segundo. A criação não é o gargalo. CAMADAS DE CACHE Camada 1 — CDN/Borda (Cloudflare, Fastly ou Nginx auto-hospedado em PoPs): - Cache de respostas 301 para links não expiráveis e não críticos para análise. Cache-Control: max-age=3600. - Usa 302 para links onde análises por clique são necessárias (a maioria dos links); estes ignoram o cache da CDN, mas ainda se beneficiam da proximidade geográfica. - Taxa de acerto estimada da CDN para links populares: 40–60% do tráfego servido na borda sem atingir a origem. Camada 2 — Cluster Redis Regional: - Cobre os ~40–60% restantes das solicitações que chegam à origem. - Taxa de acerto esperada do Redis: >95% das solicitações que chegam à origem. - Leituras líquidas do Cassandra: <5% de 17.400 req/segundo ≈ ~870 req/segundo — bem dentro da capacidade do Cassandra. PARTICIONAMENTO / SHARDING Cassandra: - Chave de partição = short_code. O hashing consistente do Cassandra distribui as partições uniformemente entre os nós. - Nenhum sharding manual necessário; adicione nós para rebalancear automaticamente. - Evite hotspots: short_code tem alta cardinalidade; nenhuma partição única será desproporcionalmente grande. Redis: - O Cluster Redis usa slots de hash (16.384 slots) distribuídos entre os nós. Hashes de short_code mapeiam uniformemente. - Chaves quentes (links virais) tratadas separadamente — veja a seção Confiabilidade. Kafka: - 64 partições por tópico; chave de partição = short_code. Garante processamento ordenado por link enquanto paraleliza entre consumidores. IMPLANTAÇÃO MULTIRREGIONAL Regiões: US-East, EU-West, AP-Southeast (mínimo de 3 para 99,99% de disponibilidade). Cassandra: - Replicação multi-datacenter: RF=3 por datacenter, 3 datacenters. - Gravações: LOCAL_QUORUM (2 de 3 nós no DC local) para criação — rápido e consistente dentro da região. - Leituras: LOCAL_QUORUM para redirecionamento — lê do DC mais próximo. - A replicação entre DCs é assíncrona; a consistência eventual entre regiões é aceitável para redirecionamentos (um link recém-criado pode levar <1 segundo para se propagar globalmente — aceitável). Redis: - Cluster independente por região; sem replicação entre regiões (custo e complexidade não justificados). - Falha de cache recorre à réplica local do Cassandra. DNS: - GeoDNS roteia usuários para o Gateway de API regional mais próximo. - IP Anycast para o domínio de redirecionamento garante roteamento de menor latência. Serviço de Criação: - Sem estado; implantado em cada região. IDs de worker são globalmente exclusivos (coordenados via um ZooKeeper global leve ou uma tabela de banco de dados simples com prefixo de região). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5. PLANO DE CONFIABILIDADE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CENÁRIOS DE FALHA E MITIGAÇÕES Falha de nó Redis: - O Cluster Redis promove a réplica automaticamente (geralmente <30 segundos). - Durante o failover, as solicitações recorrem ao Cassandra. O Cassandra pode lidar com o surto (~870 req/segundo normalmente; surto para ~17.000 req/segundo por <30 segundos é gerenciável com provisionamento adequado — dimensionar Cassandra para 2× carga de pico de leitura esperada). - Disjuntor no Serviço de Redirecionamento: se o Redis estiver totalmente indisponível, ignore o cache e leia diretamente do Cassandra. Falha de nó Cassandra: - RF=3 com LOCAL_QUORUM significa que 1 falha de nó é transparente; 2 falhas de nó degradam para LOCAL_ONE (ainda funcional, ligeiramente menos consistente). - O protocolo de gossip do Cassandra detecta falhas em segundos; o hinted handoff garante que as gravações não sejam perdidas. Falha de região inteira: - Verificações de integridade do GeoDNS detectam indisponibilidade da região em 30–60 segundos e redirecionam o tráfego para a próxima região mais próxima. - A replicação entre DCs do Cassandra garante que os dados estejam disponíveis nas regiões sobreviventes. - Meta: RTO < 2 minutos, RPO = 0 para metadados de link (gravações de quorum síncronas dentro do DC; replicação assíncrona entre DCs significa <1 segundo de potencial perda de dados para criações muito recentes — aceitável). CHAVES QUENTES (LINKS VIRAIS) Problema: Um único código curto viral pode gerar milhões de solicitações/segundo, sobrecarregando um único slot Redis ou partição Cassandra. Mitigações: 1. Cache local na memória em cada instância do Serviço de Redirecionamento (por exemplo, Caffeine, LRU de 10.000 entradas, TTL de 30 segundos). Absorve solicitações repetidas dentro de um único pod sem atingir o Redis. 2. Replicação de chave Redis: para chaves quentes detectadas (monitoradas via Redis MONITOR ou um contador de janela deslizante), replique a chave para vários slots Redis com um sufixo (por exemplo, aB3xYz:0, aB3xYz:1 ... aB3xYz:N) e selecione aleatoriamente um na leitura. 3. Cache CDN: para links não analíticos, envie links quentes para a CDN com um TTL curto (60 segundos) para absorver o tráfego na borda. 4. Cassandra: chaves quentes não são um problema porque o Redis absorve >99% das leituras para links quentes. RECUPERAÇÃO DE DESASTRES - Cassandra: snapshots diários para S3 (nodetool snapshot). A replicação entre regiões fornece DR ao vivo. - Redis: persistência Redis (AOF + RDB) em disco local; Redis é um cache — a perda é aceitável (recorre ao Cassandra). Nenhuma replicação Redis entre regiões necessária. - Kafka: fator de replicação 3 dentro da região; Kafka MirrorMaker 2 entre regiões replica eventos de clique para uma região secundária para DR de análise. - ClickHouse: tabelas replicadas (ReplicatedMergeTree); backups diários para S3. COMPORTAMENTO EM MODO DEGRADADO - Se o pipeline de análise (Kafka/Flink) estiver inativo: os redirecionamentos continuam sem afetar. Eventos de clique são armazenados em buffer no Kafka (retenção de 7 dias); as análises se recuperam quando o pipeline é recuperado. O SLA para análise (frescor de 15 minutos) pode ser violado temporariamente — aceitável. - Se o Serviço de Criação estiver inativo: redirecionamentos existentes continuam funcionando (o caminho de leitura é independente). A criação de novos links falha graciosamente com 503. - Se o Cassandra estiver degradado (quorum indisponível): o Serviço de Redirecionamento recorre ao modo somente Redis. Links não no Redis retornam 503 em vez de um redirecionamento incorreto. Este é um modo degradado de último recurso. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 6. APIS PRINCIPAIS E MODELOS DE DADOS PRINCIPAIS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ API REST POST /api/v1/links Requisição: { "long_url": "https://example.com/very/long/path?q=1", "custom_alias": "my-promo", // opcional "expires_at": "2026-01-01T00:00:00Z", // ISO-8601 opcional "owner_id": "uuid" // do token de autenticação } Resposta 201: { "short_code": "aB3xYz", "short_url": "https://sho.rt/aB3xYz", "long_url": "https://example.com/very/long/path?q=1", "expires_at": "2026-01-01T00:00:00Z", "created_at": "2025-01-15T10:00:00Z" } Erros: 400 (URL inválido), 409 (alias ocupado), 422 (URL bloqueado/malicioso), 429 (taxa limitada) GET /{short_code} Resposta 302: Location: <long_url> Resposta 301: Location: <long_url> (para links cacheáveis e não analíticos) Resposta 404: link não encontrado Resposta 410: link expirado ou desativado PATCH /api/v1/links/{short_code} Requisição: { "is_disabled": true } // ou atualizar expires_at Resposta 200: objeto de link atualizado Auth: proprietário apenas DELETE /api/v1/links/{short_code} Resposta 204 Auth: proprietário apenas GET /api/v1/links/{short_code}/analytics Parâmetros de consulta: from, to, granularity (hour/day), group_by (country/device/referrer) Resposta 200: { "short_code": "aB3xYz", "total_clicks": 142300, "series": [ { "timestamp": "2025-01-15T10:00:00Z", "clicks": 1200, "country": "US" }, ... ] } MODELOS DE DADOS PRINCIPAIS links (Cassandra) short_code TEXT CHAVE PRIMÁRIA long_url TEXT NÃO NULO owner_id UUID created_at TIMESTAMP expires_at TIMESTAMP (nulo; também definido como TTL da linha Cassandra) is_disabled BOOLEAN PADRÃO false is_custom BOOLEAN PADRÃO false abuse_flags INT PADRÃO 0 click_events (Kafka → S3 Parquet, bruto) event_id UUID short_code TEXT timestamp TIMESTAMP ip_hash TEXT (SHA-256 do IP, para privacidade) country_code TEXT (da consulta geo-IP) user_agent TEXT referrer TEXT region TEXT (região de serviço) analytics_hourly (ClickHouse, agregado) short_code TEXT hour DateTime country_code TEXT device_type TEXT (mobile/desktop/bot) referrer_domain TEXT click_count UInt64 unique_ips UInt64 (aproximação HyperLogLog) CHAVE PRIMÁRIA (short_code, hour, country_code, device_type) ENGINE = ReplicatedMergeTree users (PostgreSQL — tabela pequena, não no caminho quente) user_id UUID CHAVE PRIMÁRIA email TEXT ÚNICO api_key_hash TEXT rate_limit_tier TEXT created_at TIMESTAMP ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 7. MITIGAÇÃO DE ABUSOS E SEGURANÇA ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ DETECÇÃO DE URL MALICIOSO 1. Verificação da API Safe Browsing no momento da criação: envie long_url para o Google Safe Browsing (ou equivalente) antes de armazenar. Rejeite com 422 se sinalizado. Latência: ~50–100 ms, aceitável dentro do SLA de criação de 300 ms. 2. Lista de bloqueio de domínios: mantenha um Redis SET de domínios conhecidos como ruins (phishing, malware). Verifique síncronamente na criação. Atualizado a cada hora a partir de feeds de inteligência de ameaças. 3. Reescaneamento assíncrono: um trabalho em segundo plano periodicamente reexamina os URLs armazenados contra listas de bloqueio atualizadas. Se um URL anteriormente limpo for posteriormente sinalizado, defina is_disabled=true e abuse_flags=1. O Serviço de Redirecionamento verifica is_disabled em cada solicitação (do cache). 4. Normalização de URL: analise e normalize URLs na criação para evitar ofuscação (por exemplo, truques de codificação de URL, ataques de homógrafos em nomes de domínio — verifique homógrafos IDN). LIMITAÇÃO DE TAXA - Limite de taxa por IP no Gateway de API: 10 criações/minuto para anônimos, 100/minuto para usuários autenticados, configurável por nível. - Contador de janela deslizante baseado em Redis (token bucket) por IP/usuário. - Limite de taxa global: 10.000 criações/segundo em todo o sistema (bem acima do pico esperado de 460/segundo). - Caminho de redirecionamento: sem limite de taxa (público); proteção DDoS via CDN (mitigação DDoS Cloudflare ou equivalente). PREVENÇÃO DE ENUMERAÇÃO - Códigos curtos não são puramente sequenciais (ofuscação XOR Snowflake ou geração aleatória). - Nenhum endpoint de API para listar todos os códigos curtos. - Tentativas de redirecionamento em massa não autenticadas (>1.000 códigos únicos/minuto de um IP) acionam um desafio CAPTCHA ou bloqueio temporário de IP. AUTENTICAÇÃO E AUTORIZAÇÃO - Chave de API ou OAuth 2.0 JWT para endpoints de criação e gerenciamento. - PATCH/DELETE exigem verificação de propriedade (owner_id corresponde ao token). - API de administrador (endpoint interno separado) para a equipe de abuso desativar links. PRIVACIDADE - Endereços IP são hasheados (SHA-256 + salt por implantação) antes do armazenamento em análises. IPs brutos nunca são persistidos. - GDPR: os usuários podem solicitar a exclusão de seus links e análises associadas. Cassandra DELETE + tag de ciclo de vida S3 para eventos brutos. IMPOSIÇÃO DE HTTPS - Todos os URLs curtos servidos apenas via HTTPS. Solicitações HTTP são redirecionadas para HTTPS na borda. - Cabeçalho HSTS no domínio curto. PREVENÇÃO DE REDIRECIONAMENTO ABERTO - Redireciona apenas para URLs que foram explicitamente registrados. Nenhuma construção dinâmica de URL a partir da entrada do usuário no momento do redirecionamento. - Valida o esquema long_url na criação: apenas http:// e https:// permitidos. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 8. COMPROMISSOS E JUSTIFICATIVAS PRINCIPAIS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ COMPROMISSO 1: 302 vs 301 para redirecionamentos - 301 (permanente) é cacheado pelo navegador indefinidamente → menor latência, carga zero no servidor para visitas repetidas. Mas as análises são perdidas (o navegador nunca mais chama o servidor), e desativar/expirar um link é impossível para clientes cacheados. - 302 (temporário) atinge o servidor a cada vez → análises completas, desativação/expiração instantânea. Latência ligeiramente maior para visitas repetidas. - Decisão: Usa 302 por padrão para todos os links. Oferece 301 como opção para usuários que explicitamente desejam cache máximo e não precisam de análises. Este é o padrão correto para um serviço que vende análises. COMPROMISSO 2: Cassandra vs. banco de dados relacional para metadados de link - Banco de dados relacional (PostgreSQL) seria mais simples de operar e suporta consultas mais ricas. Mas a escala horizontal para 46 gravações/segundo em média (com picos de 10–20×) e 17.000 leituras/segundo é dolorosa sem complexidade significativa de sharding. - Cassandra sacrifica o suporte a consultas ricas (sem joins, índices secundários limitados) em troca de escalabilidade horizontal linear e replicação multi-DC. Como a única consulta quente é a consulta de chave única por short_code, esse compromisso é totalmente aceitável. COMPROMISSO 3: Consistência eventual para propagação de links entre regiões - Um link criado em US-East pode não estar imediatamente visível em AP-Southeast (atraso de sub-segundo). Um usuário que cria um link e o compartilha imediatamente globalmente pode ver um breve 404 em regiões distantes. - Alternativa: gravações síncronas entre regiões (EACH_QUORUM) — garante consistência global, mas adiciona 100–200 ms de latência à criação (viola o SLA de 300 ms em condições adversas) e reduz a disponibilidade. - Decisão: Aceitar consistência eventual. A janela de propagação de sub-segundo é um compromisso de experiência do usuário aceitável. Documentá-la. O SLA de criação é atendido. COMPROMISSO 4: IDs Snowflake vs. códigos aleatórios - IDs Snowflake são monotonicamente crescentes → ligeiramente previsíveis, mas sem risco de colisão, sem necessidade de verificação de banco de dados, operacionalmente simples. - Códigos aleatórios → maior imprevisibilidade, mas exigem verificação de colisão (rara, mas adiciona latência e complexidade). - Decisão: Snowflake + ofuscação XOR para códigos gerados automaticamente. Oferece um bom equilíbrio entre simplicidade, desempenho e imprevisibilidade razoável. Códigos aleatórios disponíveis como opção para casos de uso sensíveis à segurança. COMPROMISSO 5: Pipeline de análise separado vs. gravações síncronas - Gravar análises síncronamente em um banco de dados a cada redirecionamento adicionaria latência ao caminho crítico e criaria um gargalo de gravação a 17.000 req/segundo. - O pipeline assíncrono Kafka desacopla completamente as análises do caminho de redirecionamento. O custo é a consistência eventual nas análises (até 15 minutos) e complexidade operacional adicional (Kafka + Flink + ClickHouse). - Decisão: Pipeline assíncrono. O requisito de frescor de 15 minutos para análises permite explicitamente isso. O caminho de redirecionamento deve ser rápido; as análises podem atrasar. COMPROMISSO 6: Escopo do cache CDN - Cachear todos os redirecionamentos na CDN (301) daria desempenho máximo, mas quebraria as análises e desativaria/expiraria. - Cachear apenas links não analíticos e não expiratórios na CDN é um meio-termo. - Decisão: A CDN armazena em cache apenas links explicitamente marcados como cacheáveis (opt-in 301). Todos os outros usam 302 com Cache-Control: no-store. Este é o padrão correto para um serviço onde as análises são um recurso principal. COMPROMISSO 7: ClickHouse vs. Druid vs. BigQuery para análises - BigQuery: totalmente gerenciado, sem operações, mas alta latência de consulta (segundos) e custo nesse volume de eventos. - Druid: excelente para análises em tempo real, mas operacionalmente complexo (nós ZooKeeper, Broker, Historical, MiddleManager). - ClickHouse: mais simples de operar que Druid, excelente desempenho de consulta, custo-benefício em hardware commodity, boa integração com Kafka. - Decisão: ClickHouse. Melhor equilíbrio entre simplicidade operacional, desempenho e custo para este caso de uso. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ RESUMO DE CAPACIDADE (IMPLANTAÇÃO DE 3 REGIÕES) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Serviço de Redirecionamento: ~30 pods × 3 regiões (auto-escalado, sem estado) Serviço de Criação: ~5 pods × 3 regiões Cassandra: 9 nós × 3 regiões (RF=3 por DC), ~2 TB SSD cada Cluster Redis: 6 nós × 3 regiões, 50 GB RAM cada Kafka: 3 brokers × 3 regiões Flink: 10 gerenciadores de tarefas × 3 regiões ClickHouse: 4 nós × 3 regiões (replicado) S3: ~27 TB de eventos brutos/90 dias + ~3 TB agregados/2 anos Custo estimado da infraestrutura mensal: $15.000–$25.000 (VMs de nuvem commodity), dominado pelo armazenamento Cassandra e memória Redis. A saída da CDN é o maior custo variável em escala.