Projetar um Serviço Global de Encurtamento de URLs

### 1. Arquitetura de Alto Nível O sistema é projetado como um serviço globalmente distribuído e multirregional para garantir baixa latência e alta disponibilidade. Cada região principal (por exemplo, US-East, EU-West, AP-Southeast) hospeda uma Rede de Presença (PoP) completa. **Componentes:** 1. **Balanceador de Carga Global (GLB):** Usa roteamento DNS baseado em latência para direcionar os usuários para o PoP regional saudável mais próximo. 2. **Pilha de PoP Regional:** * **Gateway de API:** Termina TLS, autentica requisições e as roteia para o serviço de backend apropriado. * **Serviço de Redirecionamento:** Um serviço leve e altamente escalado que lida com requisições `GET /{alias_curto}`. É otimizado para velocidade. * **Serviço de Escrita:** Lida com a criação de links (`POST /api/v1/links`), incluindo validação de alias personalizado e geração de ID único. * **Serviço de Análise:** Fornece acesso a estatísticas de links via `GET /api/v1/links/{alias_curto}/stats`. 3. **Infraestrutura de Dados:** * **Banco de Dados Global:** Um banco de dados distribuído e fortemente consistente para o mapeamento principal de links. * **Cache Regional:** Um cache em memória em cada região para links populares. * **Pipeline de Análise:** Uma fila de mensagens para ingestão de eventos, um processador de fluxo para agregação e um banco de dados NoSQL para armazenar e servir dados de análise. **Fluxo de Dados:** * **Criação de Link:** A requisição `POST` de um usuário é roteada para o Serviço de Escrita mais próximo. O serviço gera ou valida um alias e grava o mapeamento `alias_curto -> URL_longa` no Banco de Dados Global. A escrita é replicada sincronicamente em todas as regiões em até 2 segundos. * **Redirecionamento:** Uma requisição `GET` é roteada para o Serviço de Redirecionamento mais próximo. Ele primeiro verifica o Cache Regional. Em caso de acerto no cache, ele imediatamente emite um redirecionamento 301 e envia assincronamente um evento de clique para a fila de análise. Em caso de erro no cache, ele consulta a réplica local do Banco de Dados Global, preenche o cache, e então realiza o redirecionamento e o registro do evento. * **Análise:** Eventos de clique de todas as regiões são publicados em uma fila de mensagens central. Um processador de fluxo consome esses eventos, os agrega em estatísticas de janela de tempo (cliques totais, cliques em 24h, contagens por país) e grava os resultados no Banco de Dados de Análise. ### 2. Escolhas de Armazenamento * **Mapeamentos de Links (Armazenamento Primário):** * **Tecnologia:** Um banco de dados SQL globalmente distribuído como Google Cloud Spanner ou CockroachDB. * **Justificativa:** Essa escolha é impulsionada pela necessidade de consistência forte em redirecionamentos e pelo requisito de propagação global de escrita inferior a 2 segundos. Esses bancos de dados fornecem replicação síncrona e leituras regionais de baixa latência, justificando seu custo mais alto para a função comercial principal. O `alias_curto` serve como chave primária para buscas rápidas. * **Links Populares em Cache:** * **Tecnologia:** Um cache distribuído em memória regional como Redis Cluster. * **Justificativa:** Com 8 bilhões de leituras diárias e tráfego altamente concentrado, um cache é essencial para atender à meta de latência P95 de <80ms e proteger o banco de dados. Cada região mantém seu próprio cache usando um padrão de cache-aside. * **Dados de Análise:** * **Fila de Ingestão:** Apache Kafka ou AWS Kinesis. Isso desacopla o caminho de redirecionamento de alto rendimento do processamento de análise e fornece um buffer durável para eventos de clique. * **Banco de Dados de Serviço:** Um armazenamento NoSQL de colunas largas como Apache Cassandra ou ScyllaDB. É otimizado para a carga de trabalho de agregação de séries temporais e alta escrita da análise e é mais econômico em escala para esses padrões de consulta do que um banco de dados relacional. ### 3. Geração de ID e Estratégia de Alias Usaremos um alias de 7 caracteres do alfabeto `[a-zA-Z0-9]`, fornecendo `62^7` (mais de 3,5 trilhões) combinações únicas. * **Geração de ID:** Um serviço em segundo plano pré-gera um grande pool de IDs únicos e aleatórios e os armazena em uma fila dedicada (por exemplo, uma lista Redis). O Serviço de Escrita simplesmente busca um ID pré-gerado desse pool quando um novo link é criado. Essa abordagem é rápida, escalável e evita verificações de colisão em tempo real durante uma requisição do usuário. * **Tratamento de Alias Personalizado:** Quando um usuário envia um alias personalizado, o Serviço de Escrita tenta `INSERT`-lo no Banco de Dados Global. A coluna `alias_curto` é a chave primária com uma restrição de unicidade. Isso lida atomicamente com a operação de verificação e definição; se o alias já estiver em uso, o banco de dados rejeita a escrita, e o serviço retorna um erro `409 Conflict` ao usuário. ### 4. Design da API * **Criar Link:** `POST /api/v1/links` * **Corpo:** `{ "long_url": "...", "custom_alias": "..." (opcional), "expires_at": "..." (opcional) }` * **Resposta:** `201 Created` com `{ "short_url": "...", "long_url": "..." }` * **Redirecionamento:** `GET /{alias_curto}` * **Resposta:** `301 Moved Permanently` com cabeçalho `Location: {url_longa}` para links permanentes. `404 Not Found` se o alias não existir ou estiver expirado. * **Obter Análise:** `GET /api/v1/links/{alias_curto}/stats` * **Resposta:** `200 OK` com `{ "total_clicks": ..., "clicks_last_24h": ..., "top_countries": [...] }` ### 5. Abordagem de Escalabilidade * **Chaves Populares:** Uma estratégia de cache de várias camadas é empregada. Para links extremamente virais, a resposta de redirecionamento `301` pode ser armazenada em cache na camada de CDN. A defesa primária é o cache Redis regional, que absorverá a maior parte do tráfego concentrado. * **Particionamento:** O Banco de Dados Global (Spanner/CockroachDB) lida automaticamente com o particionamento dos dados de link por sua chave primária (`alias_curto`). O Banco de Dados de Análise (Cassandra) será particionado por `alias_curto` para co-localizar todas as estatísticas de um determinado link, permitindo consultas eficientes. * **Tráfego Multirregional:** O GLB garante que os usuários sejam roteados para o PoP mais próximo para baixa latência. A arquitetura é ativa-ativa, pois as escritas podem ser tratadas por qualquer região e são replicadas globalmente pelo banco de dados. Esse design maximiza a utilização de recursos e a disponibilidade. ### 6. Estratégia de Confiabilidade * **Failover:** O GLB realiza verificações de integridade e roteará automaticamente o tráfego para longe de qualquer região não íntegra. Dentro de uma região, os balanceadores de carga rotearão em torno de instâncias de serviço com falha. * **Replicação de Dados:** O Banco de Dados Global é configurado para replicar dados entre múltiplas zonas de disponibilidade e regiões, fornecendo resiliência contra falhas de instância e regionais. O cluster Cassandra para análise também será implantado em várias regiões. * **Backup:** Instantâneos automatizados e periódicos dos bancos de dados primário e de análise são feitos e armazenados em armazenamento de objetos durável (por exemplo, AWS S3) para recuperação de desastres. * **Degradação Graciosa:** O sistema é projetado de forma que uma falha no pipeline de análise não crítico não afete a funcionalidade principal de redirecionamento. O Serviço de Redirecionamento continuará a atender às requisições mesmo que não consiga publicar eventos na fila de mensagens. ### 7. Compromissos e Alternativas Rejeitadas * **Alternativa 1: Geração de ID Baseada em Hash (Rejeitada). * **Conceito:** Gerar um ID curto com hash da URL longa. Se ocorrer uma colisão, adicionar um salt e re-hashear. * **Motivo da Rejeição:** Isso adiciona latência e complexidade imprevisíveis ao caminho de escrita. Com 120 milhões de escritas por dia, a probabilidade de colisão se torna significativa, exigindo múltiplas consultas ao banco de dados para encontrar um ID único. A estratégia de pré-geração escolhida fornece desempenho de tempo constante para aquisição de ID durante uma requisição do usuário. * **Alternativa 2: Banco de Dados Relacional Master Único (Rejeitado). * **Conceito:** Usar um banco de dados tradicional como PostgreSQL em uma única região primária com réplicas de leitura em outras regiões. * **Motivo da Rejeição:** Esse design não pode atender ao requisito estrito de propagação global de escrita de `<2 segundos`. O atraso de replicação para réplicas de leitura distantes excederia frequentemente esse limite, o que significa que um link recém-criado não estaria imediatamente disponível para todos os usuários globais. O custo mais alto de um banco de dados globalmente distribuído é justificado para atender a esse requisito funcional principal.

SERVIÇO GLOBAL DE ENCURTAMENTO DE URLS — DESIGN DE SISTEMA ───────────────────────────────────────── 1. ARQUITETURA DE ALTO NÍVEL E FLUXO DE DADOS ───────────────────────────────────────── O sistema é organizado em três planos: o Caminho de Escrita (criação de links), o Caminho de Leitura (redirecionamento) e o Caminho de Análise (ingestão e consulta de eventos). Componentes principais: - Balanceador de Carga Global Anycast / Borda de CDN (por exemplo, Cloudflare ou AWS CloudFront com Lambda@Edge) - Gateway de API + Camada de Autenticação (limitação de taxa, prevenção de abusos) - Serviço de Criação de Links (sem estado, escalável horizontalmente) - Serviço de Redirecionamento (sem estado, extremamente sensível à latência) - Serviço de Geração de ID (produtor distribuído de códigos curtos únicos) - Armazenamento Primário de Links (banco de dados relacional replicado globalmente, por exemplo, CockroachDB ou AWS Aurora Global) - Cache de Links Quentes (Cluster Redis, por região) - Fila de Ingestão de Análises (Kafka ou AWS Kinesis, por região) - Workers de Agregação de Análises (processadores de stream, por exemplo, Flink ou Kafka Streams) - Armazenamento de Análises (armazenamento colunar, por exemplo, ClickHouse ou Apache Druid) - Serviço de Consulta de Análises (API somente leitura) - Armazenamento de Objetos para backups frios (compatível com S3) Caminho de Escrita (criação de links): 1. O cliente envia POST para o Gateway de API regional mais próximo. 2. O Gateway de API autentica e limita a taxa da solicitação, em seguida, encaminha para o Serviço de Criação de Links. 3. O Serviço de Criação de Links chama o Serviço de Geração de ID para obter um código curto exclusivo (ou valida um alias personalizado). 4. O registro é gravado no Armazenamento Primário de Links com forte consistência na região local; a replicação global do banco de dados propaga o registro para outras regiões em cerca de 1–2 segundos, atendendo ao SLA de "utilizável em 2 segundos globalmente". 5. Simultaneamente, o novo mapeamento é enviado para o cache Redis regional (write-through ou invalidação pub/sub) para que o primeiro redirecionamento nessa região não perca o cache. 6. Uma resposta 201 com a URL curta é retornada ao cliente. Caminho de Leitura (redirecionamento): 1. O cliente emite GET /{codigoCurto} para o nó de borda mais próximo. 2. O nó de borda verifica seu próprio cache de CDN (para links extremamente quentes, TTL de ~5–10 segundos para respeitar a semântica de expiração). 3. Em caso de falha no cache da CDN, a solicitação atinge o Serviço de Redirecionamento regional. 4. O Serviço de Redirecionamento verifica o cache Redis regional (taxa de acerto esperada > 99% para links quentes). 5. Em caso de falha no Redis, o Serviço de Redirecionamento consulta a réplica de leitura local do Armazenamento Primário de Links. 6. Se o link expirou ou não foi encontrado, retorna 404/410. 7. Caso contrário, emite um redirecionamento HTTP 301 (permanente) ou 302 (temporário). Usa 302 por padrão para que os navegadores não armazenem em cache indefinidamente, preservando a precisão das análises. 8. Emite assincronamente um evento de clique (codigoCurto, timestamp, país derivado do IP, user-agent) para a Fila de Ingestão de Análises regional. Isso é fire-and-forget; não bloqueia a resposta de redirecionamento. Caminho de Análise: 1. Tópicos Kafka regionais recebem eventos de clique. 2. Jobs Flink/Kafka Streams consomem eventos e mantêm agregações contínuas: cliques totais (contador), cliques nas últimas 24 horas (janela deslizante) e os 5 principais países (esboço aproximado de heavy-hitter, por exemplo, Count-Min Sketch ou SpaceSaving). 3. Os resultados agregados são gravados no ClickHouse (armazenamento colunar otimizado para anexação) a cada 30–60 segundos. 4. O Serviço de Consulta de Análises lê do ClickHouse e retorna resultados pré-agregados. Eventos brutos também são retidos no ClickHouse para consultas ad-hoc. 5. Agregação de análises entre regiões: o cluster Kafka de cada região espelha eventos para uma região central de análises via Kafka MirrorMaker 2 ou replicação entre regiões do Kinesis. O cluster ClickHouse central detém a visão global. ───────────────────────────────────────── 2. ESCOLHAS DE ARMAZENAMENTO ───────────────────────────────────────── Mapeamentos de Links — CockroachDB (ou Aurora Global DB): Justificativa: Precisamos de forte consistência para escritas (para evitar aliases duplicados) e leituras de baixa latência globalmente. CockroachDB é um banco de dados SQL distribuído com suporte ativo-ativo multirregional, isolamento serializável e failover automático. Aurora Global DB é uma alternativa com um gravador primário único e até 5 réplicas de leitura em diferentes regiões com cerca de 1 s de latência de replicação. Qualquer um atende ao SLA de propagação global de 2 segundos. Esquema (simplificado): links(short_code VARCHAR(12) PK, long_url TEXT NOT NULL, owner_id BIGINT, created_at TIMESTAMPTZ, expires_at TIMESTAMPTZ, is_custom BOOLEAN) Índices: short_code (PK, clusterizado), owner_id + created_at (para painéis de usuário). Tamanho estimado: 120M links/dia × 365 dias × ~300 bytes/linha ≈ ~13 TB/ano. Gerenciável com particionamento por created_at. Cache de Links Quentes — Cluster Redis (por região): Cada região executa um Cluster Redis com 3–6 shards e réplicas. Entradas de cache: short_code → {long_url, expires_at}. TTL definido para min(expiração do link, 24 horas). Conjunto de trabalho esperado: os 1% principais de links (~1,2M) respondem por ~80% do tráfego. Com ~500 bytes por entrada, 1,2M de entradas ≈ 600 MB por região — muito acessível. Usamos uma estratégia write-through na criação de links e população preguiçosa na primeira falha de redirecionamento. Eventos de Análise — Kafka + ClickHouse: Kafka retém eventos de clique brutos por 7 dias (replayability). ClickHouse armazena eventos brutos (particionados por data, sharded por short_code) e visualizações materializadas pré-agregadas. O armazenamento colunar e a execução vetorizada do ClickHouse o tornam ideal para as consultas de agregação necessárias (SUM, COUNT, GROUP BY country, janela deslizante). Backups Frios — Armazenamento de objetos compatível com S3: Snapshots diários do armazenamento de links e exportações semanais do ClickHouse são armazenados em armazenamento de objetos com versionamento e replicação entre regiões para recuperação de desastres. ───────────────────────────────────────── 3. ESTRATÉGIA DE GERAÇÃO DE ID E ALIAS ───────────────────────────────────────── Formato do Código Curto: Use 7 caracteres de um alfabeto Base62 (a-z, A-Z, 0-9). Base62^7 = ~3,5 trilhões de combinações, excedendo em muito qualquer necessidade previsível (120M/dia × 10 anos = ~438B links). Estratégia de Geração de ID — Contador Distribuído + Codificação: Usamos uma abordagem de contador distribuído em vez de geração aleatória para evitar tempestades de colisão em escala. Passo 1: Cada instância do Serviço de Criação de Links adquire um bloco de IDs de um serviço de coordenação leve (por exemplo, um INCRBY do Redis ou um serviço de ID dedicado com backend ZooKeeper). Cada instância reivindica um bloco de 10.000 IDs por vez, reduzindo a sobrecarga de coordenação. Passo 2: O ID numérico é codificado em Base62 para produzir o código curto. Um código Base62 de 7 caracteres pode representar IDs de até ~3,5 trilhões. Passo 3: Para evitar ataques de enumeração e adicionar imprevisibilidade, faça XOR do ID numérico com um salt secreto antes de codificar, ou use uma função de embaralhamento bijetiva (cifra de Feistel sobre o espaço de IDs). Aliases Personalizados: 1. O cliente envia o alias desejado (3–20 caracteres alfanuméricos). 2. O Serviço de Criação de Links tenta um INSERT com o alias personalizado como short_code usando uma restrição de unicidade no banco de dados. 3. Se o INSERT falhar devido a uma violação de restrição de unicidade, retorna HTTP 409 Conflict com uma sugestão para tentar outro alias. 4. Aliases personalizados ignoram completamente o serviço de geração de ID. 5. Aliases personalizados são reservados em uma verificação de namespace separada (lista de palavrões, palavras reservadas como "api", "admin", "health") antes da escrita no banco de dados. Tratamento de Colisão para Códigos Gerados: Como usamos um contador monotonicamente crescente com codificação bijetiva, colisões são estruturalmente impossíveis para códigos gerados. Colisões só podem ocorrer se um código gerado corresponder a um alias personalizado — isso é tratado pela restrição de unicidade; o serviço de geração de ID simplesmente incrementa para o próximo ID e tenta novamente (extremamente raro). ───────────────────────────────────────── 4. DESIGN DE API ───────────────────────────────────────── Todas as APIs são RESTful sobre HTTPS. A limitação de taxa é aplicada na camada do Gateway de API (por exemplo, 100 criações/minuto por usuário autenticado, 10 criações/minuto para usuários anônimos). POST /v1/links — Criar Link Curto Corpo da solicitação (JSON): long_url: string (obrigatório, deve ser uma URL válida, máx. 2048 caracteres) custom_alias: string (opcional, 3–20 caracteres alfanuméricos) expires_at: data/hora ISO 8601 (opcional) owner_id: string (opcional, do token de autenticação) Resposta 201 Created: short_code: string short_url: string (por exemplo, "https://sho.rt/aB3xY7z") long_url: string expires_at: string ou null created_at: string Resposta 400: URL ou formato de alias inválido Resposta 409: alias personalizado já em uso Resposta 429: limite de taxa excedido GET /{shortCode} — Redirecionamento Sem corpo de solicitação. Parâmetro de caminho: shortCode. Resposta 302 Found com cabeçalho Location definido para long_url. Resposta 404: código curto não encontrado. Resposta 410 Gone: link expirou. Este endpoint é servido no domínio raiz (por exemplo, sho.rt/{shortCode}) para comprimento mínimo da URL. GET /v1/links/{shortCode}/analytics — Recuperar Análises Autenticação necessária (proprietário ou administrador). Parâmetros de consulta: nenhum necessário (retorna resumo padrão) Resposta 200: short_code: string total_clicks: inteiro clicks_last_24h: inteiro top_countries: array de objetos, cada um com country_code (ISO 3166-1 alpha-2) e click_count, ordenado decrescente, máx. 5 entradas last_updated: data/hora ISO 8601 (indica a atualidade das análises) Resposta 404: link não encontrado. Resposta 403: não autorizado. GET /v1/links/{shortCode} — Obter Metadados do Link (endpoint utilitário opcional) Autenticação necessária. Resposta 200: objeto de link completo incluindo long_url, created_at, expires_at, is_custom. DELETE /v1/links/{shortCode} — Excluir / Desativar Link Autenticação necessária (proprietário ou administrador). Resposta 204 No Content. Exclui logicamente o registro (define um timestamp deleted_at) e invalida a entrada de cache via pub/sub. ───────────────────────────────────────── 5. ABORDAGEM DE ESCALABILIDADE ───────────────────────────────────────── Problema de Chave Quente: Uma pequena fração de links (URLs virais, campanhas de marketing) receberá milhões de redirecionamentos por minuto. O sharding ingênuo do Redis coloca todo o tráfego de uma chave em um único shard. Mitigação: - Cache local na memória em cada instância do Serviço de Redirecionamento (por exemplo, Caffeine com um LRU de 10.000 entradas, TTL de 5 segundos). Isso absorve as chaves mais quentes inteiramente dentro do processo, eliminando idas e vindas ao Redis para os 0,1% principais de links. - Cache de borda da CDN com um TTL curto (5–10 segundos) para a própria resposta de redirecionamento. Com 8B de redirecionamentos/dia, mesmo uma taxa de acerto de CDN de 90% descarrega 7,2B de solicitações da origem. - Réplicas de leitura do Redis: promova shards de chaves quentes para ter mais réplicas e roteie leituras round-robin. Estratégia de Cache: Cache de três níveis: borda da CDN → LRU na memória → Cluster Redis → réplica de leitura do banco de dados. População do cache: write-through na criação, preguiçosa na primeira falha. Invalidação do cache: na exclusão ou expiração do link, publique uma mensagem de invalidação em um canal Redis pub/sub; todas as instâncias do Serviço de Redirecionamento assinam e removem a chave de seu LRU local. As entradas da CDN expiram naturalmente via TTL. Particionamento: - Armazenamento de Links: particione por hash de short_code (CockroachDB lida com isso automaticamente via sharding baseado em intervalos). Sem partições quentes porque os códigos curtos são distribuídos uniformemente após o embaralhamento bijetivo. - Kafka: particione eventos de clique por hash de short_code. Isso garante que todos os eventos para um determinado link vão para a mesma partição, permitindo agregação stateful por link sem embaralhamentos. - ClickHouse: shard por short_code, particione por data. Consultas para análises de um único link atingem um shard; consultas de intervalo de tempo se beneficiam da poda de partições. Tráfego Multirregional: Implante em três regiões: Leste dos EUA, Oeste da Europa, Sudeste Asiático (cobre América do Norte, Europa, Ásia). - GeoDNS baseado em DNS ou Anycast roteia usuários para a região mais próxima. - Cada região é totalmente independente para leituras (Serviço de Redirecionamento + Redis + réplica de leitura do banco de dados). - Escritas (criação de links) vão para o Serviço de Criação de Links da região mais próxima, que escreve no nó local do banco de dados distribuído globalmente. CockroachDB se replica para outras regiões em cerca de 1–2 segundos. - Eventos de análise são processados regionalmente e espelhados para um cluster central de análise para agregação global. Esboço de Capacidade: - 8B redirecionamentos/dia = ~92.500 req/s em média, ~300.000 req/s no pico (fator 3x). - Com taxa de acerto de CDN de 90%: ~30.000 req/s para a origem em 3 regiões = ~10.000 req/s por região. - Cada instância do Serviço de Redirecionamento pode lidar com ~5.000 req/s (principalmente acertos de cache, CPU mínima). ~2–4 instâncias por região em carga média, escalando automaticamente para 20+ no pico. - 120M escritas/dia = ~1.400 escritas/s em média. O Serviço de Criação de Links não é o gargalo. ───────────────────────────────────────── 6. ESTRATÉGIA DE CONFIABILIDADE ───────────────────────────────────────── Meta de Disponibilidade: 99,99% = ~52 minutos de inatividade/ano. Failover: - Cada região executa várias instâncias de cada serviço sem estado atrás de um balanceador de carga regional com verificações de integridade (fail open: remove instâncias não íntegras em 10 segundos). - O Cluster Redis usa failover automático: se um shard primário falhar, uma réplica é promovida em ~15 segundos. Durante essa janela, o Serviço de Redirecionamento recorre à réplica de leitura do banco de dados (latência ligeiramente maior, mas correta). - Se uma região inteira falhar, o GeoDNS detecta a falha por meio de sondagens de integridade e redireciona o tráfego para a região adjacente mais próxima em ~30–60 segundos. As regiões restantes devem absorver a carga; o escalonamento automático cuida disso. - CockroachDB / Aurora Global DB: failover automático para o nó de outra região se a região primária estiver indisponível. Para Aurora, isso envolve uma promoção manual ou automatizada de uma réplica de leitura para primária (RTO ~1 minuto com automação). Replicação de Dados: - Armazenamento de Links: replicação síncrona dentro de uma região (pelo menos 2 nós), replicação assíncrona entre regiões (consenso do CockroachDB entre regiões, ou Aurora Global DB ~1 s de latência). Aceitamos consistência eventual para leituras entre regiões porque o SLA de propagação de 2 segundos é atendido. - Redis: cada shard tem pelo menos uma réplica na mesma região. Sem replicação Redis entre regiões (Redis é um cache; o banco de dados é a fonte da verdade). - Kafka: fator de replicação 3 dentro de cada região. Espelhamento entre regiões apenas para análises (não para correção de redirecionamento). - ClickHouse: replicado dentro da região de análise usando ClickHouse Keeper (substituto do ZooKeeper). Nenhuma replicação ClickHouse multirregional necessária, pois as análises são eventualmente consistentes. Backup: - Backups lógicos diários do Armazenamento de Links para armazenamento de objetos (S3), retidos por 30 dias. - Exportações completas semanais do ClickHouse para armazenamento de objetos, retidas por 90 dias. - Dados do tópico Kafka retidos por 7 dias (atuam como um buffer de replay para recuperação de análises). - A restauração de backup é testada mensalmente por meio de exercícios de restauração automatizados em um ambiente de staging. Comportamento de Degradação: - Se o Redis estiver indisponível: o Serviço de Redirecionamento recorre às réplicas de leitura do banco de dados. A latência aumenta, mas a correção é mantida. Alerta e escala automática das réplicas de leitura do banco de dados. - Se a Fila de Análises estiver indisponível: eventos de clique são descartados (análises são eventualmente consistentes; aceitamos essa perda). Redirecionamentos nunca são bloqueados por falhas de análise. Um circuit breaker no Serviço de Redirecionamento desabilita a emissão de eventos se a fila estiver não íntegra. - Se o Armazenamento de Links primário estiver indisponível: a criação de novos links falha (retorna 503). Redirecionamentos continuam usando dados em cache e réplicas de leitura. Isso é aceitável porque a criação é menos crítica do que a disponibilidade de redirecionamento. - Se uma região estiver completamente inativa: failover GeoDNS para a região adjacente. Os usuários experimentam latência maior, mas o serviço permanece disponível. - Limitação de taxa e detecção de abusos no Gateway de API impedem que ataques DDoS sobrecarreguem o sistema. ───────────────────────────────────────── 7. PRINCIPAIS COMPROMISSOS E ALTERNATIVAS REJEITADAS ───────────────────────────────────────── Compromisso 1: Redirecionamentos 302 vs. 301 Escolhemos 302 (redirecionamento temporário) como padrão. 301 (permanente) permitiria que os navegadores armazenassem em cache o redirecionamento indefinidamente, reduzindo a carga na origem. No entanto, 301 torna impossível rastrear cliques repetidos do mesmo navegador, quebra as análises e nos impede de atualizar ou expirar links (o navegador serviria o redirecionamento em cache para sempre). O custo do 302 é maior tráfego na origem, o que mitigamos com CDN e cache na memória. Para links explicitamente marcados como permanentes pelo proprietário (e sem expiração), poderíamos oferecer 301 como opt-in, mas o padrão é 302. Compromisso 2: Códigos Curtos Aleatórios vs. Codificação Baseada em Contador Rejeitado: Gerar strings Base62 aleatórias de 7 caracteres e verificar colisões no banco de dados. Motivo da rejeição: Com 120M de links/dia e um espaço de códigos de 3,5T, a probabilidade de colisão começa baixa, mas aumenta com o tempo. Mais importante, cada criação requer uma leitura do banco de dados para verificar a colisão, seguida por uma escrita — duas idas e vindas sob contenção. Com uma abordagem baseada em contador, o ID é garantido como exclusivo por construção; nenhuma verificação de colisão é necessária. O serviço de contador é uma sobrecarga de coordenação menor, mas é muito mais barato do que verificações de colisão no banco de dados em escala. A etapa de embaralhamento bijetivo preserva o benefício de imprevisibilidade dos códigos aleatórios. Compromisso 3: Análises Síncronas vs. Fila Assíncrona Rejeitado: Escrever eventos de clique de forma síncrona no banco de dados de análises durante a solicitação de redirecionamento. Motivo da rejeição: Isso adicionaria 10–50 ms de latência a cada redirecionamento (uma escrita no ClickHouse ou banco de dados de análises no caminho crítico), violando o SLA de P95 < 80 ms. Também cria uma dependência rígida entre a disponibilidade de redirecionamento e a disponibilidade de análises. A abordagem de fila assíncrona desacopla essas preocupações completamente. O custo é que as análises são eventualmente consistentes (atraso de 30–60 segundos), o que é explicitamente aceitável de acordo com os requisitos. Compromisso 4: Banco de Dados Global Único vs. Banco de Dados Ativo-Ativo Multirregional Escolhemos um banco de dados distribuído globalmente (CockroachDB ou Aurora Global) em vez de um primário de região única com réplicas de leitura em todos os lugares. Um primário de região única nos daria semânticas de consistência mais simples, mas faria com que todas as escritas fossem para uma região (alta latência para usuários em outras regiões criando links e um único ponto de falha para escritas). O banco de dados distribuído globalmente custa mais e adiciona complexidade operacional, mas é justificado porque a latência de criação de links e a disponibilidade de escrita são importantes para a experiência do usuário e a meta de disponibilidade de 99,99%. Compromisso 5: ClickHouse vs. um Banco de Dados de Séries Temporais (por exemplo, InfluxDB) para Análises Rejeitado: InfluxDB ou TimescaleDB para armazenamento de análises. Motivo da rejeição: Bancos de dados de séries temporais são otimizados para métricas com um conjunto fixo de tags. Nossas consultas de análise exigem GROUP BY country flexível, janelas de tempo arbitrárias e potencialmente junções com metadados de links. O armazenamento colunar do ClickHouse, a interface SQL e as visualizações materializadas lidam com esses padrões de forma mais natural e em maior escala. O ClickHouse também suporta agregações aproximadas (quantis, heavy-hitters) nativamente, o que é útil para a consulta dos 5 principais países em escala. ───────────────────────────────────────── RESUMO DA JUSTIFICATIVA DO ORÇAMENTO ───────────────────────────────────────── Gastar mais em: - Clusters Redis multirregionais: a latência de redirecionamento é o SLA principal; falhas de cache são caras. - Armazenamento de Links Distribuído Globalmente (CockroachDB / Aurora Global): a correção dos redirecionamentos e a propagação global de 2 segundos exigem isso. - Capacidade de borda da CDN: o investimento de maior alavancagem para latência e disponibilidade de redirecionamento. - Escalonamento automático para o Serviço de Redirecionamento: o tráfego é altamente variável e pontual. Gastar menos em: - Infraestrutura de análises: a consistência eventual é aceitável; um único cluster ClickHouse central com replicação é suficiente. Não há necessidade de replicação de análises multirregional. - Serviço de Criação de Links: o volume de escrita é de ~1.400/s, trivialmente tratado por algumas instâncias. - Armazenamento frio / backups: o armazenamento de objetos é barato; superprovisione a retenção em vez de subprovisionar. - Replicação Redis entre regiões: Redis é um cache com backup no banco de dados; a replicação entre regiões adiciona custo e complexidade com benefício mínimo, já que o banco de dados já se replica.