Projetar um Serviço Global de Encurtamento de URLs

1. Arquitetura de Alto Nível e Fluxos de Requisição: **Componentes Principais:** * **Gateway de API/Balanceadores de Carga:** Ponto de entrada para todas as requisições do usuário, lida com roteamento, autenticação e limitação de taxa. * **Serviço de Encurtamento (Shorten Service):** Microsserviço responsável pela criação, atualização e exclusão de links curtos. Lida com a validação de alias personalizados e lógica de expiração. * **Serviço de Redirecionamento (Redirect Service):** Microsserviço otimizado para alto rendimento e baixa latência de redirecionamento. Registra eventos de clique. * **Cache Distribuído (ex: Cluster Redis):** Armazenamento primário para mapeamentos de `short_code` para `long_url` para servir redirecionamentos com latência mínima. * **Banco de Dados SQL Distribuído (ex: CockroachDB, Google Spanner):** Armazena a fonte autoritativa da verdade para todos os metadados de links, garantindo exclusividade global e consistência forte. * **Fila de Mensagens (ex: Apache Kafka):** Ingesta eventos de clique de alto volume do Serviço de Redirecionamento, desacoplando-o do processamento de análise. * **Processador de Análise (ex: Apache Flink/Spark Streaming):** Consome eventos de clique da Fila de Mensagens, realiza agregação em tempo real e armazena dados. * **Data Warehouse (ex: ClickHouse, Snowflake, BigQuery):** Armazena dados brutos e agregados de análise para relatórios e análise. * **CDN (ex: Cloudflare, Akamai):** Distribui ativos estáticos, fornece resolução DNS global e pode oferecer roteamento geográfico para o data center mais próximo. **Fluxos de Requisição:** * **Criação de Link Curto:** 1. Usuário/Cliente envia uma requisição para o Gateway de API. 2. Gateway de API roteia para um Balanceador de Carga, depois para o Serviço de Encurtamento. 3. Serviço de Encurtamento gera um `short_code` único (ou valida um alias personalizado). 4. Ele armazena o `short_code`, `long_url`, `expires_at` e outros metadados no Banco de Dados SQL Distribuído. 5. Ele envia o novo mapeamento `short_code` -> `long_url` para o Cache Distribuído. 6. Serviço de Encurtamento retorna o `short_code` para o usuário. * **Redirecionamento de Link Curto:** 1. Usuário/Cliente acessa um URL curto, que é roteado via CDN/GeoDNS para o data center mais próximo do Balanceador de Carga. 2. Balanceador de Carga direciona para o Serviço de Redirecionamento. 3. Serviço de Redirecionamento primeiro verifica o Cache Distribuído para o mapeamento `short_code` -> `long_url`. 4. *Cache Hit:* Se encontrado e ativo, ele imediatamente emite um redirecionamento HTTP 301/302 para o `long_url`. 5. *Cache Miss:* Se não encontrado, ele consulta o Banco de Dados SQL Distribuído. Se encontrado e ativo, ele popula o cache e então redireciona. Se não encontrado, expirado ou excluído, ele retorna um erro 404. 6. Assincronamente, o Serviço de Redirecionamento publica um evento de clique (contendo `short_code`, `timestamp`, `country`, `device_type`, `referrer_domain`) na Fila de Mensagens. * **Processamento de Análise:** 1. Processador de Análise consome eventos de clique da Fila de Mensagens. 2. Ele realiza processamento em tempo real (ex: agregação, enriquecimento). 3. Dados brutos e agregados são armazenados no Data Warehouse para relatórios. 2. Modelo de Dados e Escolhas de Armazenamento: * **Links e Aliases (Banco de Dados SQL Distribuído - CockroachDB/Google Spanner):** * **Tabela `links`:** * `short_code` (VARCHAR, Chave Primária): O identificador curto único. * `long_url` (VARCHAR): O URL original (até 500 bytes). * `user_id` (UUID, Indexado, FK): Opcional, para propriedade do link. * `created_at` (TIMESTAMP): Quando o link foi criado. * `expires_at` (TIMESTAMP, Nulável, Indexado): Quando o link deve expirar. * `status` (ENUM: 'active', 'expired', 'deleted', Indexado): Estado atual do link. * `is_custom_alias` (BOOLEAN): Verdadeiro se for um alias definido pelo usuário. * `click_count` (BIGINT): Contagem de cliques desnormalizada e eventualmente consistente (atualizada pela análise). * *Justificativa:* Escolhido por garantias de consistência forte (crítico para a exclusividade global de `short_code` e `custom_alias`), propriedades ACID e capacidades nativas de replicação multirregional. Isso simplifica o gerenciamento global de dados e garante a integridade dos dados. * **Eventos de Análise (Fila de Mensagens - Apache Kafka, Data Warehouse - ClickHouse/Snowflake):** * **Tópico Kafka (`click_events`):** Armazena mensagens de eventos de clique brutos (ex: JSON/Protobuf). * **Data Warehouse (`raw_clicks` table):** * `event_id` (UUID, Chave Primária) * `short_code` (VARCHAR, Indexado) * `timestamp` (TIMESTAMP, Indexado) * `country` (VARCHAR, Indexado) * `device_type` (VARCHAR) * `referrer_domain` (VARCHAR) * **Data Warehouse (`aggregated_clicks` table):** (ex: agregações horárias/diárias) * `short_code` (VARCHAR, PK) * `aggregation_time` (TIMESTAMP, PK) * `country` (VARCHAR, PK) * `total_clicks` (BIGINT) * *Justificativa:* Kafka fornece ingestão de alto rendimento e tolerante a falhas e desacoplamento. ClickHouse/Snowflake são otimizados para consultas analíticas sobre grandes volumes de dados, suportando o requisito de consistência eventual para análise. 3. Estratégia de Escalabilidade para Tráfego Pesado de Leitura: * **Cache Distribuído (Cluster Redis):** Esta é a principal camada de escalabilidade para redirecionamentos. Ele armazenará mapeamentos de `short_code` para `long_url` em memória, lidando com a vasta maioria dos 4 bilhões de redirecionamentos diários. O Cluster Redis oferece escalabilidade horizontal e alta disponibilidade por meio de particionamento e replicação. * **CDN Global e Roteamento Geográfico:** Uma CDN (ex: Cloudflare) servirá ativos estáticos e fornecerá roteamento inteligente baseado em DNS (GeoDNS) para direcionar os usuários para o data center geograficamente mais próximo, minimizando a latência de redirecionamento. * **Serviços sem Estado (Stateless):** Tanto os serviços de Encurtamento quanto de Redirecionamento são projetados para serem sem estado, permitindo escalabilidade horizontal fácil adicionando mais instâncias atrás de balanceadores de carga em cada região. Grupos de autoescalonamento ajustarão dinamicamente a capacidade com base no tráfego. * **Réplicas de Leitura do Banco de Dados/Leituras Distribuídas:** O Banco de Dados SQL Distribuído lidará inerentemente com leituras distribuídas em seus nós. Se as taxas de acerto do cache forem menores que o esperado, ou para links menos populares, a capacidade do banco de dados de escalar leituras em seu cluster será crucial. * **Geração de Código Curto:** Para criação de links de alto volume, códigos curtos podem ser pré-gerados em lotes e armazenados, ou um serviço de geração de ID distribuído (ex: inspirado no Twitter Snowflake) pode ser usado para garantir códigos únicos e não sequenciais, evitando gargalos no banco de dados. 4. Estratégia de Confiabilidade: * **Failover:** * **Implantação Multirregional:** Todos os serviços críticos (Encurtamento, Redirecionamento, Banco de Dados, Cache, Fila de Mensagens) são implantados em configuração ativa-ativa em pelo menos três regiões geograficamente distintas (ex: América do Norte, Europa, Ásia). * **Failover em Nível de Serviço:** Os serviços são implantados em grupos de autoescalonamento em múltiplas Zonas de Disponibilidade dentro de cada região. Balanceadores de carga detectam e roteiam automaticamente o tráfego para longe de instâncias não saudáveis. * **Failover do Banco de Dados:** O Banco de Dados SQL Distribuído fornece replicação multirregional integrada e mecanismos de failover automáticos (ex: consenso Raft no CockroachDB) para garantir operação contínua mesmo se nós ou zonas inteiras falharem. * **Failover do Cache:** O Cluster Redis fornece replicação para redundância de dados e failover automático de nós mestres. * **Failover da Fila de Mensagens:** Clusters Kafka são implantados com replicação (ex: 3 brokers, fator de replicação 3) em múltiplas Zonas de Disponibilidade para tolerar falhas de broker. * **Decisões de Consistência:** * **Consistência Forte (Criação de Links/Aliases):** O Banco de Dados SQL Distribuído garante consistência forte para a exclusividade de `short_code` e `custom_alias`. Isso é crítico para evitar colisões e manter a integridade dos dados. * **Consistência Eventual (Redirecionamentos):** O Cache Distribuído opera com consistência eventual. Quando um link é criado, atualizado (ex: `expires_at` muda) ou excluído, um evento é publicado em um tópico de invalidação de cache (ex: Kafka). Nós do serviço de redirecionamento e cache assinam este tópico e invalidam/atualizam suas entradas. Um TTL curto (ex: 1-5 minutos) nas entradas do cache atua como um fallback para evitar desatualização indefinida. * **Consistência Eventual (Análise):** Os dados de análise são eventualmente consistentes em até 5 minutos, gerenciados pela Fila de Mensagens assíncrona e processamento de fluxo. Isso prioriza o desempenho do redirecionamento sobre atualizações imediatas de análise. * **Tratamento de Falhas Regionais:** * **Balanceamento de Carga Global/DNS:** Serviços de DNS inteligentes (ex: GeoDNS) e balanceadores de carga globais detectam automaticamente falhas regionais e redirecionam o tráfego para regiões saudáveis e ativas. * **Replicação de Dados:** O Banco de Dados SQL Distribuído replica todos os dados de links entre as regiões ativas. Se uma região ficar indisponível, outras regiões podem continuar servindo requisições com perda mínima de dados e impacto na latência. * **Degradação Graciosa:** Se o Serviço de Análise ou a Fila de Mensagens tiverem problemas, o Serviço de Redirecionamento é projetado para continuar funcionando, armazenando eventos localmente em buffer ou, em casos extremos, descartando-os, priorizando a funcionalidade principal de redirecionamento. 5. Principais Compromissos, Gargalos e Riscos: * **Principais Compromissos:** * **Consistência vs. Latência:** Consistência forte para criação de links (via SQL Distribuído) garante a integridade dos dados, mas pode incorrer em latência de escrita ligeiramente maior. Para redirecionamentos, a consistência eventual via um cache altamente otimizado é escolhida para atingir latência inferior a 80ms. * **Tamanho do Cache vs. Custo:** O cache extensivo é vital para o desempenho do redirecionamento, mas requer recursos de memória significativos, levando a custos de infraestrutura mais altos. Um equilíbrio deve ser alcançado entre a taxa de acerto do cache e a despesa operacional. * **Comprimento do Código Curto vs. Tamanho do Namespace:** Códigos mais curtos são mais amigáveis ao usuário, mas aumentam a probabilidade de colisões e limitam o número total de links únicos. Um código base62 de 7-10 caracteres fornece um namespace prático e vasto. * **Gargalos:** * **Capacidade do Cache Distribuído:** Se o cache não conseguir lidar com o rendimento de leitura de pico ou se o conjunto de trabalho ativo de links exceder sua capacidade de memória, os redirecionamentos voltarão ao banco de dados, aumentando a latência e a carga do banco de dados. * **Rendimento de Escrita do Banco de Dados:** Embora a criação de links seja de menor volume que os redirecionamentos, 120 milhões de links/dia é substancial. O Banco de Dados SQL Distribuído deve ser capaz de lidar com essa carga de escrita entre regiões sem se tornar um gargalo. * **Latência de Rede entre Regiões:** A replicação de dados entre regiões e as verificações de consistência, especialmente para operações de escrita em um sistema distribuído globalmente, podem introduzir latência inerente. * **Riscos e Mitigações:** * **Risco 1: Colisões de Código Curto (especialmente para geração aleatória):** * *Mitigação:* Use um `short_code` suficientemente longo (ex: 7-10 caracteres usando base62: a-z, A-Z, 0-9). Implemente uma estratégia de geração robusta: pré-gere um grande pool de códigos únicos, use um gerador de ID distribuído (ex: semelhante ao Snowflake) para gerar IDs únicos e depois converta para base62, ou para aliases personalizados, realize uma verificação direta de exclusividade no banco de dados com bloqueio otimista e retentativas. * **Risco 2: Desatualização do Cache para Links Expirados/Excluídos:** * *Mitigação:* Implemente um mecanismo de invalidação de cache em tempo real. Quando o status de um link muda (ex: `expires_at` atingido, `status` definido como 'deleted'), o Serviço de Encurtamento (ou um trabalho em segundo plano dedicado) publica um evento em um tópico Kafka. Todas as instâncias do Serviço de Redirecionamento e nós de cache assinam este tópico e invalidam imediatamente a entrada correspondente do `short_code`. Um TTL curto (ex: 1-5 minutos) nas entradas do cache atua como fallback. * **Risco 3: Gargalos no Banco de Dados devido à distribuição desigual de `short_code`:** * *Mitigação:* Para bancos de dados SQL Distribuídos, confie em suas capacidades internas de particionamento e rebalanceamento. Para aliases personalizados, o próprio alias serve como chave primária, que deve se distribuir bem. Para códigos curtos gerados aleatoriamente, garanta que o algoritmo de geração produza códigos suficientemente aleatórios para evitar chaves sequenciais que possam levar a gargalos. Monitore as partições do banco de dados e rebalanceie conforme necessário. 6. Estimativa de Capacidade: * **Rendimento:** * **Redirecionamentos:** 4 bilhões/dia = ~46.300 requisições/segundo (média), pico de ~138.900 requisições/segundo (3x média). * **Criação de Links:** 120 milhões/dia = ~1.389 requisições/segundo (média), pico de ~4.167 requisições/segundo (3x média). * **Ingestão de Eventos de Análise:** ~46.300 eventos/segundo (média), pico de ~138.900 eventos/segundo. * **Armazenamento:** * **Dados de Links (Banco de Dados SQL Distribuído):** * Tamanho médio do registro: ~100 bytes (short_code, long_url, timestamps, status, etc.). * Novos links diários: 120 milhões * 100 bytes = 12 GB. * Total ao longo de 5 anos: 12 GB/dia * 365 dias/ano * 5 anos = ~21,9 TB. * Com fator de replicação 3x para alta disponibilidade/multirregional: ~65,7 TB. * **Dados de Análise (Data Warehouse):** * Tamanho médio do evento: ~100 bytes (short_code, timestamp, country, device, referrer). * Eventos diários: 4 bilhões * 100 bytes = 400 GB. * Total ao longo de 1 ano de retenção: 400 GB/dia * 365 dias/ano = ~146 TB. * Com fator de replicação 3x: ~438 TB. * **Cache Distribuído (Cluster Redis):** * Cada entrada em cache: `short_code` (ex: 10 bytes) + `long_url` (média 500 bytes) = ~510 bytes. * Para armazenar 1 bilhão de links ativos (um conjunto de trabalho razoável de links populares): 1 bilhão de links * 510 bytes/link = 510 GB de memória de cache. Este é um tamanho significativo, mas gerenciável para um Cluster Redis grande e particionado.

## Serviço Global de Encurtamento de URLs - Design do Sistema ### 1. Arquitetura de Alto Nível **Componentes Principais:** - **Gateway de API e Balanceador de Carga**: Ponto de entrada global com roteamento regional (América do Norte, Europa, Ásia) - **Serviço de Links Curtos**: Lida com a criação, validação e gerenciamento de aliases - **Serviço de Redirecionamento**: Otimizado para redirecionamentos de alto rendimento com latência mínima - **Camada de Cache**: Cache multinível (CDN de ponta, Redis regional, memória local) - **Armazenamento de Dados Primário**: Banco de dados SQL distribuído (PostgreSQL com particionamento) para metadados de links - **Pipeline de Análise**: Streaming de eventos (Kafka) → Processador de fluxo (Flink/Spark) → Banco de dados de análise (ClickHouse/Druid) - **CDN**: Entrega de conteúdo global para respostas de redirecionamento - **Fila de Mensagens**: Para operações assíncronas (expiração, exclusão, análise) - **Monitoramento e Observabilidade**: Rastreamento distribuído, métricas, alertas **Fluxos de Solicitação:** *Criar Link Curto:* 1. Cliente → Gateway de API (regional) 2. Serviço de Links Curtos valida a entrada, gera código curto ou valida alias personalizado 3. Verifica a exclusividade do alias no cache distribuído + banco de dados primário 4. Grava no banco de dados primário (com replicação) 5. Invalida o cache, publica evento no Kafka 6. Retorna o link curto (p95 < 300ms) *Redirecionamento (Leitura):* 1. Cliente → Local de ponta da CDN mais próximo 2. CDN verifica o cache local; se ausente, roteia para o cache regional (Redis) 3. Ausência no cache regional → Consulta ao banco de dados primário com réplica de leitura 4. Resposta em cache na ponta da CDN e no Redis regional 5. Retorna redirecionamento 301/302 (p95 < 80ms) 6. Assíncrono: publica evento de clique no Kafka *Análise:* 1. Eventos de clique → Tópico Kafka 2. Processador de fluxo agrega por link_id, país, dispositivo, referenciador 3. Grava métricas agregadas no banco de dados de análise a cada 1-5 minutos 4. Painel consulta o banco de dados de análise para relatórios --- ### 2. Modelo de Dados e Escolhas de Armazenamento **Tabela de Metadados de Links (Banco de Dados Primário - PostgreSQL):** ``` links: - link_id (UUID, chave primária) - short_code (VARCHAR(10), índice único) - long_url (TEXT, máx. 500 bytes) - user_id (UUID, indexado) - custom_alias (VARCHAR(100), índice global único, nulo) - created_at (TIMESTAMP) - expires_at (TIMESTAMP, nulo, indexado) - is_deleted (BOOLEAN, indexado) - is_custom (BOOLEAN) - created_region (VARCHAR(10)) - metadata (JSONB: título, descrição, tags) ``` **Tabela de Eventos de Análise (Banco de Dados de Séries Temporais - ClickHouse):** ``` click_events: - event_id (UUID) - link_id (UUID, indexado) - timestamp (DateTime) - country (VARCHAR(2)) - device_type (VARCHAR(20)) - referrer_domain (VARCHAR(255)) - user_agent (VARCHAR(500)) - ip_hash (VARCHAR(64)) ``` **Justificativa das Escolhas de Armazenamento:** - **PostgreSQL (Primário)**: Garantias ACID para criação de links, consistência forte para exclusividade de alias, comprovado em escala com particionamento adequado - **Redis (Cache Regional)**: Latência sub-milissegundo para links populares, suporta TTL para expiração automática, distribuído entre regiões - **ClickHouse (Análise)**: Otimizado para análise de séries temporais, armazenamento colunar reduz o armazenamento em 10-100x, agregações rápidas - **CDN (Cloudflare/Akamai)**: Cache de ponta global, reduz a latência para <80ms p95, descarrega o tráfego de origem - **Kafka (Fluxo de Eventos)**: Desacopla a análise do caminho de redirecionamento, permite repetição, suporta múltiplos consumidores --- ### 3. Estratégia de Escalabilidade para Tráfego com Predominância de Leitura **Arquitetura de Cache (Multinível):** 1. **Cache de CDN de Ponta** (Nível 1): - Cache de respostas de redirecionamento globalmente - TTL: 24 horas para links ativos, 5 minutos para links expirados - Chave de cache: short_code - Meta de taxa de acerto: 95%+ - Reduz o tráfego de origem em 95% 2. **Cluster Redis Regional** (Nível 2): - 3 regiões: us-east, eu-west, ap-southeast - Cada região: cluster Redis com 6 nós (3 primários, 3 réplicas) - Replicação entre zonas de disponibilidade - TTL: 1 hora para links, 5 minutos para links expirados - Capacidade: 500 GB por região (apenas links populares) 3. **Cache na Memória Local** (Nível 3): - Cache LRU por instância de serviço (100 MB) - Reduz viagens de ida e volta ao Redis para os 1% de links mais populares **Estratégia de Réplica de Leitura:** - Banco de dados primário em us-east (mestre de gravação) - Réplicas de leitura em eu-west, ap-southeast (replicação assíncrona, atraso de ~100ms) - Roteia leituras para a réplica mais próxima - Fallback para o primário se a réplica estiver indisponível **Escalabilidade Horizontal:** - Serviço de Redirecionamento: Auto-escala para mais de 1000 instâncias entre regiões - Cada instância lida com ~4 milhões de redirecionamentos/dia (4 bilhões / 1000) - Balanceador de carga distribui com base na latência e capacidade **Geração de Código Curto:** - Codificação Base62 (0-9, a-z, A-Z) para códigos de 6 caracteres - 62^6 = 56 bilhões de códigos possíveis (suficiente para 120 milhões/dia por mais de 400 anos) - Gerador de ID distribuído (semelhante ao Snowflake) com prefixo de região para evitar colisões - Alocação em lote: cada instância de serviço pré-aloca 10 mil códigos --- ### 4. Estratégia de Confiabilidade **Failover e Alta Disponibilidade:** - **Implantação multirregional**: Ativo-ativo em 3 regiões - **Replicação de banco de dados**: Replicação de streaming PostgreSQL com failover automático (Patroni) - **Disjuntores (Circuit Breakers)**: Evitam falhas em cascata quando o cache/DB está indisponível - **Degradação graciosa**: Se o banco de dados de análise estiver inativo, ainda atende redirecionamentos; enfileira eventos localmente **Decisões de Consistência:** - **Consistência forte para gravações**: A criação de links usa bloqueios distribuídos (Redis/Zookeeper) para exclusividade de alias - **Consistência eventual para leituras**: Respostas de redirecionamento podem estar desatualizadas em ~100ms (aceitável) - **Consistência eventual para análise**: Janela de 5 minutos aceitável conforme requisitos - **Tratamento de expiração**: Exclusão preguiçosa (verifica expires_at na leitura) + trabalho em segundo plano (escaneia a cada hora) **Tratamento de Falha Regional:** 1. **Detectar falha**: Verificações de integridade falham por 30 segundos 2. **Failover**: Roteia tráfego para outras regiões 3. **Operações de gravação**: Roteia para a região primária (us-east) com fallback para a região local 4. **Operações de leitura**: Usa réplicas de leitura em outras regiões 5. **Recuperação**: Sincroniza dados do primário quando a região se recupera 6. **Monitoramento**: Alerta sobre indisponibilidade da região, rastreia eventos de failover **Mitigações Específicas:** - **Falha do banco de dados**: Failover automático do Patroni para réplica (RTO < 30s) - **Falha do cache**: Ignora para o DB com limitação de taxa para evitar thundering herd - **Falha da CDN**: Roteia tráfego diretamente para o cache regional - **Partição de rede**: Assume que a partição se cura; usa decisões baseadas em quorum - **Corrupção de dados**: Recuperação point-in-time de backups (snapshots diários) --- ### 5. Principais Compromissos, Gargalos e Riscos **Compromissos:** 1. **Consistência vs. Latência**: Escolheu-se consistência eventual para análise para manter a latência de redirecionamento <80ms. Consistência forte para exclusividade de alias adiciona ~50ms, mas é necessária para correção. 2. **TTL do Cache vs. Atualidade**: TTL de 24 horas da CDN reduz a carga de origem, mas significa que links expirados podem redirecionar por até 24 horas. Mitigado por TTL de 5 minutos para links marcados como excluídos. 3. **Armazenamento vs. Velocidade de Consulta**: Desnormaliza dados de análise (armazena país, dispositivo na tabela de eventos) para permitir agregações rápidas, aceitando sobrecarga de armazenamento de 2-3x. 4. **Autonomia Regional vs. Consistência Global**: Cada região pode atender leituras independentemente, mas as gravações devem coordenar para exclusividade de alias, adicionando latência. **Gargalos:** 1. **Verificação de Exclusividade de Alias**: Bloqueio distribuído global necessário; pode se tornar ponto de contenção durante picos de gravação. Mitigação: Usa scripts Lua com Redis para verificação e configuração atômicas; particiona pelo primeiro caractere do alias. 2. **Taxa de Transferência de Gravação do Banco de Dados**: 120 milhões de novos links/dia = ~1.400 gravações/segundo. PostgreSQL pode lidar com ~10.000 gravações/segundo por instância, então são necessárias 1-2 instâncias primárias. Mitigação: Agrupa gravações, usa pool de conexões (PgBouncer). 3. **Pipeline de Análise**: 4 bilhões de cliques/dia = ~46.000 eventos/segundo. Kafka pode lidar com isso, mas a agregação pode atrasar. Mitigação: Usa processador de fluxo (Flink) para agregação em tempo real; grava no banco de dados de análise a cada 1 minuto. **Três Principais Riscos e Mitigações:** **Risco 1: Cache Stampede na Expiração de Link Popular** - *Cenário*: Link viral com 1 milhão de cliques/hora expira; todas as entradas de cache são invalidadas simultaneamente; 1 milhão de solicitações atingem o DB - *Impacto*: Sobrecarga do DB, latência de redirecionamento aumenta para segundos, violação do SLA - *Mitigação*: - Usa expiração antecipada probabilística: atualiza o cache 5 minutos antes da expiração real - Implementa coalescência de solicitações: se várias solicitações atingirem um link expirado, apenas a primeira consulta ao DB - Define taxa máxima de consulta ao DB com disjuntor; retorna 404 se excedida - Pré-aquece o cache para links que expiram conhecidos **Risco 2: Colisão de Alias Distribuído Sob Partição de Rede** - *Cenário*: Partição de rede entre regiões; dois usuários criam o mesmo alias personalizado em regiões diferentes; a partição se cura; conflito de dados - *Impacto*: Exclusividade do alias violada; um link se torna inacessível; inconsistência de dados - *Mitigação*: - Usa bloqueio distribuído global (Zookeeper/etcd) para gravações de alias; falha se o bloqueio estiver indisponível - Implementa resolução de conflitos: vencedor baseado em timestamp (a escrita anterior vence) - Trabalho de auditoria: verifica aliases duplicados diariamente; alerta sobre conflitos - Exige que as gravações de alias passem apenas pela região primária (aceita maior latência) **Risco 3: Perda de Dados de Análise Durante Falha no Processamento de Fluxo** - *Cenário*: Consumidor Kafka trava; eventos não processados; atraso na análise aumenta; memória enche; eventos são descartados - *Impacto*: Contagens de cliques imprecisas; métricas de negócios não confiáveis; perda de confiança do cliente - *Mitigação*: - Usa grupos de consumidores Kafka com gerenciamento de offset; retoma do último offset confirmado - Implementa fila de mensagens mortas (dead-letter queue) para eventos com falha; repete manualmente - Define limites de memória no buffer de eventos local; descarta eventos mais antigos se cheio (com alerta) - Gravação dupla de análise: Kafka → Processador de fluxo E gravações diretas no DB (com desduplicação) - Monitora o atraso do consumidor; alerta se o atraso for > 5 minutos --- ### 6. Estimativas de Capacidade **Armazenamento:** *Metadados de Links (PostgreSQL):* - 120 milhões de novos links/dia × 365 dias = 43,8 bilhões de links/ano - Por link: 50 bytes (IDs, timestamps, flags) + 500 bytes (URL longa) + 100 bytes (metadados) = 650 bytes - Ano 1: 43,8 bilhões × 650B = 28,5 TB - Com retenção de 3 anos: 85,5 TB - Com replicação (3x): 256,5 TB - Particionado em 10 instâncias: 25,6 TB por instância (gerenciável) *Eventos de Análise (ClickHouse):* - 4 bilhões de cliques/dia × 365 dias = 1,46 trilhão de eventos/ano - Por evento: 50 bytes (IDs, timestamps) + 100 bytes (país, dispositivo, referenciador) = 150 bytes - Ano 1: 1,46 trilhão × 150B = 219 TB (não compactado) - Compressão do ClickHouse: 10-20x → 11-22 TB/ano - Retenção de 3 anos: 33-66 TB (aceitável) *Cache (Redis):* - Links populares (1% do total): 438 milhões de links - Por link em cache: 50 bytes (short_code, ponteiro long_url) = 50 bytes - 438 milhões × 50B = 22 GB por região - 3 regiões: 66 GB total (cabe na alocação de 500 GB por região) **Taxa de Transferência:** *Taxa de Transferência de Gravação:* - 120 milhões de links/dia ÷ 86.400 segundos = 1.389 gravações/segundo - PostgreSQL: 1 instância primária lida com 10.000 gravações/segundo → 1 instância suficiente - Kafka: 1.389 eventos/segundo → 1 partição suficiente (Kafka lida com mais de 100.000 msgs/segundo por partição) *Taxa de Transferência de Leitura:* - 4 bilhões de redirecionamentos/dia ÷ 86.400 segundos = 46.296 leituras/segundo - Pico (3x): 138.888 leituras/segundo - Taxa de acerto do cache da CDN: 95% → 6.944 leituras/segundo para a origem - Taxa de acerto do Redis: 99% das ausências → 70 leituras/segundo para o DB - PostgreSQL: 1 réplica de leitura por região lida com 10.000 leituras/segundo → 1 réplica por região suficiente - Instâncias do Serviço de Redirecionamento: 46.000 leituras/segundo ÷ 100 leituras/segundo por instância = 460 instâncias (base), 1.389 instâncias no pico *Taxa de Transferência de Análise:* - 4 bilhões de cliques/dia = 46.296 eventos/segundo - Kafka: 1 tópico, 10 partições (paralelismo) - Processador de fluxo: 10 instâncias, cada uma lida com 4.630 eventos/segundo - ClickHouse: Inserções em lote a cada 1 minuto; 46.000 eventos/min = gerenciável **Largura de Banda da Rede:** *Respostas de redirecionamento:* - 46.000 redirecionamentos/segundo × 300 bytes (resposta HTTP) = 13,8 MB/segundo - Pico: 41,4 MB/segundo - CDN absorve 95% → 2,1 MB/segundo para a origem no pico - Facilmente gerenciado por conexão de 1 Gbps *Eventos de análise:* - 46.000 eventos/segundo × 500 bytes = 23 MB/segundo - Cluster Kafka: capacidade de 10 Gbps → suficiente **Tabela Resumo:** | Componente | Capacidade | Instâncias | Notas | |---|---|---|-------| | PostgreSQL Primário | 10K gravações/seg | 1 | Particionado para crescimento futuro | | Réplicas de Leitura PostgreSQL | 10K leituras/seg | 3 (1 por região) | Replicação assíncrona | | Clusters Redis | 100K ops/seg | 3 (1 por região) | 6 nós cada | | Serviço de Redirecionamento | 100 redirecionamentos/seg | 460 (base), 1.389 (pico) | Auto-escala | | Brokers Kafka | 100K msgs/seg | 3 | Fator de replicação 3 | | Processadores de Fluxo | 4.630 eventos/seg | 10 | Flink/Spark | | Nós ClickHouse | 1M inserções/seg | 3 | Cluster distribuído | | Locais de Ponta da CDN | Global | 200+ | Cloudflare/Akamai | --- ### Prioridades de Implementação 1. **Fase 1** (MVP): Região única, PostgreSQL + Redis + CDN, análise básica 2. **Fase 2** (Escala): Multirregional, réplicas de leitura, pipeline de análise Kafka 3. **Fase 3** (Otimizar): Geração de ID distribuída, cache avançado, análise ClickHouse 4. **Fase 4** (Fortalecer): Disjuntores, engenharia de caos, simulações de recuperação de desastres