Projetar um Serviço Global de Encurtamento de URLs

Projeto: Serviço Global de Encurtamento de URLs 1. REQUISITOS E ESTIMATIVAS GERAIS Requisitos funcionais: - Criar um link curto para uma dada URL longa (com alias personalizado opcional). - Redirecionar visitantes do link curto para a URL original (HTTP 301/302). - Análises básicas: cliques totais por link, cliques por dia nos últimos 30 dias. Requisitos não funcionais: - 120 milhões de novos links por mês, cerca de 46 gravações por segundo em média, pico em torno de 200 por segundo. - 1,2 bilhão de redirecionamentos por mês, cerca de 463 por segundo em média, pico em torno de 5.000-50.000 por segundo para links virais. - 99,99% de disponibilidade de redirecionamento. - Redirecionamentos globais de baixa latência. - Links válidos por pelo menos 5 anos. - Análises eventualmente consistentes em até 10 minutos. - Prevenção básica de abusos. Estimativa de armazenamento: - 120 milhões de links por mês vezes 60 meses (5 anos) igual a 7,2 bilhões de links. - Cada registro de link com cerca de 500 bytes (código curto, URL longa, metadados) resulta em cerca de 3,6 TB de dados de links ao longo de 5 anos. - Dados de análises são adicionais, mas gerenciáveis com agregação. 2. ARQUITETURA DE ALTO NÍVEL O sistema é composto pelos seguintes componentes principais: a) Gateway de API e Balanceador de Carga: Ponto de entrada para todo o tráfego. Lida com terminação TLS, limitação de taxa, autenticação para criação de links e roteamento. Implantado em várias regiões atrás de um DNS anycast global ou um balanceador de carga global (por exemplo, AWS Global Accelerator ou Cloudflare). b) Serviço de Criação de Links: Serviço sem estado que lida com requisições POST para criar novos links curtos. Valida a entrada, gera ou reserva códigos curtos, verifica a disponibilidade de alias personalizados, aplica verificações básicas de abuso e grava no banco de dados principal. c) Serviço de Redirecionamento: Serviço sem estado e otimizado para leitura que lida com requisições GET para códigos curtos. Procura o código curto primeiro no cache, depois no banco de dados, e retorna um redirecionamento HTTP 301 ou 302. Também emite um evento de clique assincronamente para análises. d) Serviço de Análises: Consome eventos de clique de uma fila de mensagens, os agrega e armazena contagens diárias e totais. Atende a consultas de análises. e) Camada de Cache: Cache distribuído (clusters Redis ou Memcached) implantado em cada região para atender a códigos curtos populares com latência de sub-milissegundos. f) Banco de Dados Primário: Armazena os mapeamentos canônicos de links. Um banco de dados distribuído como Amazon DynamoDB, Google Cloud Spanner ou CockroachDB. g) Fila de Mensagens: Kafka ou Amazon Kinesis para buffer de eventos de clique entre o serviço de redirecionamento e o pipeline de análises. h) CDN / Camada de Borda: Para os links mais populares, as respostas de redirecionamento podem ser cacheadas na borda da CDN (usando 301 com cabeçalhos de cache apropriados ou workers de borda que realizam a consulta). Fluxo da arquitetura: - Criação de link: Cliente -> Gateway de API -> Serviço de Criação de Links -> DB Primário (gravação) -> Invalida/popula cache -> Retorna URL curta. - Redirecionamento: Cliente -> CDN/Borda -> (cache miss) -> Gateway de API -> Serviço de Redirecionamento -> Cache -> (cache miss) -> DB -> Retorna redirecionamento 302. Emite assincronamente evento de clique para fila de mensagens. - Consulta de análises: Cliente -> Gateway de API -> Serviço de Análises -> DB de Análises -> Retorna resultados. 3. MODELO DE DADOS E ARMAZENAMENTO Tabela de Mapeamento de Links (Armazenamento Primário - DynamoDB ou similar): - short_code (chave de partição): string, 7 caracteres, por exemplo, "aB3x9Kz" - long_url: string, a URL original, até 2048 caracteres - user_id: string, opcional, o criador - custom_alias: booleano, se este foi um alias personalizado - created_at: timestamp - expires_at: timestamp (created_at + 5 anos por padrão) - click_count: inteiro (contador eventualmente consistente, atualizado periodicamente) - status: enum (ativo, desativado, expirado) Por que DynamoDB: O padrão de consulta de chave-valor única é perfeito. Ele escala horizontalmente com latência consistente de milissegundos de um único dígito. A chave de partição é o short_code, que distribui bem dada a natureza aleatória dos códigos gerados. Armazenamento de Análises: - Opção A: Uma tabela de séries temporais no DynamoDB ou Cassandra com chave de partição = short_code e chave de ordenação = data (AAAA-MM-DD), com um atributo click_count. - Opção B: Contagens diárias pré-agregadas armazenadas em uma tabela separada, com um TTL de 30 dias para as linhas de granularidade diária. Esquema para tabela de análises diárias: - short_code (chave de partição): string - date (chave de ordenação): string, formato AAAA-MM-DD - click_count: inteiro - TTL: timestamp, 30 dias a partir da data Isso permite consultas de intervalo eficientes: obter todas as contagens diárias para um short_code nos últimos 30 dias. Para contagens totais de cliques, mantemos um contador em execução na tabela principal de mapeamento de links, atualizado pelo pipeline de análises. 4. ESTRATÉGIA DE GERAÇÃO DE ID / TOKEN Requisitos: 7,2 bilhões de códigos únicos ao longo de 5 anos. Usando codificação base62 (a-z, A-Z, 0-9), um código de 7 caracteres fornece 62^7 = 3,5 trilhões de combinações possíveis, o que é mais do que suficiente. Abordagem: Faixas de ID pré-geradas usando um contador distribuído ou alocação baseada em faixas. Estratégia principal: - Usar um serviço central de geração de ID (como Twitter Snowflake ou um serviço de contador mais simples) que aloca blocos de IDs numéricos para cada instância do Serviço de Criação de Links. Por exemplo, cada instância solicita um bloco de 10.000 IDs por vez. - Cada ID numérico é então codificado para base62 para produzir o código curto de 7 caracteres. - Isso evita coordenação em cada gravação, garantindo exclusividade global. Alternativa considerada: Geração aleatória com verificação de colisão. Isso funciona, mas requer uma leitura antes da gravação para verificar colisões, adicionando latência. Com 7,2 bilhões de códigos de 3,5 trilhões possíveis, a probabilidade de colisão é baixa (cerca de 0,2%), mas ainda requer a verificação. A abordagem baseada em faixas é mais determinística. Tratamento de alias personalizados: - Quando um usuário solicita um alias personalizado, o serviço executa uma gravação condicional (PutItem com condição de que o short_code não exista ainda) no banco de dados. - Se a condição falhar, o alias está em uso e retornamos um erro ao usuário. - Alias personalizados são validados: mínimo de 4 caracteres, máximo de 30 caracteres, alfanuméricos mais hifens, verificados contra uma lista de bloqueio de palavras reservadas e termos ofensivos. - Alias personalizados são armazenados na mesma tabela que os códigos gerados, com o sinalizador custom_alias definido como true. 5. DESIGN DA API Todas as APIs são RESTful sobre HTTPS. a) Criar Link Curto: POST /api/v1/links Cabeçalhos: Authorization: Bearer <token> (opcional para anônimo, obrigatório para acesso a análises) Corpo da requisição: long_url: obrigatório, a URL de destino (validada quanto ao formato e segurança básica) custom_alias: opcional, código curto desejado expires_in_days: opcional, padrão 1825 (5 anos) Resposta (201 Created): short_code: "aB3x9Kz" short_url: "https://sho.rt/aB3x9Kz" long_url: "https://example.com/very/long/path" created_at: "2025-01-15T10:30:00Z" expires_at: "2030-01-15T10:30:00Z" Respostas de erro: 400 (URL inválida), 409 (alias personalizado em uso), 429 (taxa limitada) b) Redirecionar: GET /{short_code} Resposta: 302 Found com cabeçalho Location definido para a URL longa. Usamos 302 (redirecionamento temporário) em vez de 301 (redirecionamento permanente) para que os navegadores não cacheadem o redirecionamento permanentemente, permitindo-nos rastrear cliques e potencialmente atualizar o destino. No entanto, para desempenho, podemos usar 301 na borda da CDN com um TTL apropriado. Respostas de erro: 404 (não encontrado ou expirado), 410 (desativado) c) Obter Análises: GET /api/v1/links/{short_code}/analytics Cabeçalhos: Authorization: Bearer <token> Resposta (200 OK): short_code: "aB3x9Kz" total_clicks: 154302 daily_clicks: lista de objetos com data e contagem para os últimos 30 dias Respostas de erro: 401 (não autorizado), 404 (link não encontrado) d) Excluir / Desativar Link: DELETE /api/v1/links/{short_code} Cabeçalhos: Authorization: Bearer <token> Resposta: 204 No Content 6. ESTRATÉGIA DE CACHE, PARTITIONAMENTO E REPLICAÇÃO Cache: - Camada 1 - Cache de Borda da CDN: Para o caminho de redirecionamento, podemos cachear respostas 302 na borda da CDN com um TTL curto (por exemplo, 5 minutos). Isso lida extremamente bem com links virais, já que a CDN absorve a maioria do tráfego. Usamos cabeçalhos Cache-Control com um max-age curto. - Camada 2 - Cluster Redis Regional: Cada região tem um cluster Redis que armazena em cache mapeamentos de short_code para long_url. TTL do cache de 24 horas. Política de evicção LRU. - Camada 3 - Cache local em nível de aplicativo: Cada instância do serviço de redirecionamento mantém um pequeno cache LRU em memória (por exemplo, 100 mil entradas) para os links mais acessados. Tamanho do cache: Com 1,2 bilhão de redirecionamentos por mês e uma distribuição de Zipf, os 20% principais de links provavelmente respondem por 80% do tráfego. Cachear os 10 milhões de links ativos principais no Redis requer aproximadamente 10 milhões vezes 300 bytes = 3 GB por região, o que é muito gerenciável. Invalidação de cache: Na exclusão ou atualização de um link, publicamos um evento de invalidação para todas as regiões via fila de mensagens. As entradas de cache também têm TTLs como rede de segurança. Particionamento: - O DynamoDB particiona automaticamente pela chave hash do short_code. A natureza aleatória dos códigos gerados garante distribuição uniforme. - Para alias personalizados, a distribuição é menos previsível, mas a capacidade adaptativa do DynamoDB lida com partições quentes. - O Redis é particionado usando hashing consistente entre os nós do cluster. Replicação: - As Tabelas Globais do DynamoDB fornecem replicação multirregional com consistência eventual (geralmente sub-segundo). Designamos uma região como primária para gravações (criação de links) e todas as regiões podem atender a leituras. - Alternativamente, com CockroachDB ou Spanner, obtemos leituras multirregionais fortemente consistentes, mas com maior custo de latência para gravações. - Clusters Redis são replicados dentro de cada região (primário-réplica). O cache entre regiões é preenchido independentemente por meio de replicação de banco de dados e aquecimento de cache local. 7. ABORDAGEM DE CONFIABILIDADE Meta de disponibilidade: 99,99% para redirecionamentos significa no máximo 4,3 minutos de inatividade por mês. Implantação multirregional: - Implantar o serviço de redirecionamento em pelo menos 3 regiões geograficamente distribuídas (por exemplo, Leste dos EUA, Oeste da Europa, Sudeste Asiático). - Usar roteamento global baseado em DNS (roteamento baseado em latência do Route 53 ou anycast) para direcionar os usuários para a região mais próxima. - Cada região é capaz de atender independentemente a redirecionamentos de seu cache local e réplica do banco de dados. Tratamento de falhas: - Se a região primária do banco de dados falhar, outra região é promovida. Com Tabelas Globais do DynamoDB, qualquer região pode aceitar gravações, portanto, não há um único líder de gravação para falha. - Se o Redis em uma região falhar, o serviço de redirecionamento volta para o banco de dados. O banco de dados pode lidar com a carga temporariamente e o Redis se recupera rapidamente. - Se o pipeline de análises (Kafka) tiver problemas, os eventos de clique são armazenados em buffer. A durabilidade do Kafka garante que não haja perda de dados. A consistência eventual das análises em até 10 minutos nos dá margem. - Disjuntores são implementados entre os serviços. Se o banco de dados estiver lento, o serviço de redirecionamento atende a partir do cache e degrada graciosamente (retorna resultados cacheados ou um erro temporário para cache misses). Verificações de integridade e monitoramento: - Cada instância de serviço tem endpoints de verificação de integridade. - Balanceadores de carga removem instâncias não íntegras automaticamente. - Monitoramento abrangente com painéis para percentis de latência (p50, p95, p99), taxas de erro, proporções de acerto de cache e atraso da fila. - Alerta sobre violações de SLO. Durabilidade dos dados: - O DynamoDB fornece 99,999999999% de durabilidade com replicação entre regiões. - Backups regulares como uma rede de segurança adicional. 8. ESCALONAMENTO PARA TRÁFEGO COM MUITA LEITURA E PONTOS QUENTES VIRAIS A proporção leitura/gravação é de aproximadamente 10:1 (1,2 bilhão de leituras vs 120 milhões de gravações por mês), mas durante eventos virais, um único link pode receber milhões de acessos por hora. Estratégias: - O cache de borda da CDN é a primeira e mais eficaz defesa. A resposta de redirecionamento de um link viral é cacheada em centenas de locais de borda em todo o mundo. Mesmo um TTL de 5 minutos significa que a origem vê apenas uma requisição a cada 5 minutos por local de borda. - Computação de borda (Cloudflare Workers ou Lambda@Edge) pode realizar a consulta de redirecionamento inteiramente na borda, lendo de um armazenamento KV distribuído (como Cloudflare KV ou DynamoDB DAX), eliminando a necessidade de atingir a origem. - Autoescalonamento do cluster Redis: Monitorar a carga do cache e adicionar réplicas de leitura dinamicamente. - Autoescalonamento do serviço de redirecionamento: Serviços sem estado escalam horizontalmente com base em métricas de CPU e contagem de requisições. - Para pontos quentes extremos, o cache local em nível de aplicativo em cada instância do serviço de redirecionamento garante que, mesmo que o Redis esteja sob pressão, os links mais acessados sejam atendidos da memória. Análises durante eventos virais: - Eventos de clique são produzidos para o Kafka, que lida bem com gravações intermitentes. - O consumidor de análises pode agrupar e agregar antes de gravar no armazenamento de análises, reduzindo a amplificação de gravação. - Usamos contagem aproximada, se necessário (HyperLogLog para visitantes únicos), mas para contagens totais, contadores simples são suficientes. 9. PREVENÇÃO DE ABUSOS Medidas básicas (confiança e segurança completas estão fora do escopo): - Limitação de taxa na criação de links: por IP e por usuário autenticado (por exemplo, 100 links por hora para anônimos, 1000 para autenticados). - Validação de URL: rejeitar URLs malformadas, verificar contra listas de bloqueio de URLs de phishing/malware conhecidas (por exemplo, API Google Safe Browsing). - Validação de alias personalizado: lista de bloqueio de palavras ofensivas e reservadas. - CAPTCHA para criação de links anônimos se os limites de taxa estiverem sendo atingidos. - Capacidade de desativar links relatados como abusivos (manual ou automatizado). - Registro e trilha de auditoria para todos os eventos de criação de links. 10. PRINCIPAIS COMPROMISSOS Consistência vs. Latência: - Escolhemos consistência eventual para o mapeamento de links entre regiões. Um link recém-criado pode não ser resolúvel em uma região distante por alguns centenas de milissegundos. Isso é aceitável porque o usuário que cria o link é roteado para a região mais próxima onde a gravação é imediatamente consistente, e a replicação entre regiões é rápida. Para análises, aceitamos explicitamente consistência eventual de 10 minutos. Redirecionamentos 302 vs. 301: - 302 (temporário) nos permite rastrear cada clique e alterar destinos, mas aumenta a carga de origem. 301 (permanente) é mais eficiente, mas os navegadores o cacheiam indefinidamente. Nosso compromisso: usar 302 da origem, mas permitir o cache na borda da CDN com um TTL curto, nos dando o melhor dos dois mundos. Custo vs. Desempenho: - O preço sob demanda do DynamoDB é mais caro por requisição do que o provisionado, mas lida com tráfego intermitente sem planejamento de capacidade. Para um serviço nessa escala, usamos capacidade provisionada com autoescalonamento para a linha de base e sob demanda para o excesso. - CDN e computação de borda adicionam custo, mas reduzem drasticamente as necessidades de infraestrutura de origem e melhoram a experiência do usuário. Complexidade Operacional vs. Confiabilidade: - A implantação multirregional com Tabelas Globais do DynamoDB adiciona complexidade operacional, mas é necessária para a meta de 99,99% de disponibilidade e o requisito de baixa latência global. - O Kafka adiciona outro sistema para operar, mas fornece o desacoplamento e a durabilidade necessários para análises confiáveis. Armazenamento vs. Computação: - Pré-agregamos contagens diárias de análises em vez de computá-las em tempo real a partir de eventos de clique brutos. Isso troca eficiência de armazenamento por desempenho de consulta e simplicidade. Exclusividade de Alias Personalizado: - Alias personalizados compartilham o mesmo namespace que os códigos gerados. Reservamos o espaço de código gerado (exatamente 7 caracteres base62) e exigimos que os alias personalizados tenham um comprimento diferente ou sejam verificados contra o intervalo gerado. Abordagem mais simples: todos os códigos (gerados e personalizados) vão para a mesma tabela, e a gravação condicional garante a exclusividade independentemente. 11. RESUMO DAS ESCOLHAS DE TECNOLOGIA - Balanceamento de Carga Global: AWS Global Accelerator ou Cloudflare com DNS anycast - CDN e Borda: CloudFront ou Cloudflare com workers de borda - Computação: Clusters Kubernetes ou ECS/Fargate em cada região para serviços sem estado - Banco de Dados Primário: Tabelas Globais do DynamoDB (mapeamentos de links e análises diárias) - Cache: Clusters Redis ElastiCache em cada região - Fila de Mensagens: Amazon Kinesis ou Apache Kafka (MSK) para eventos de clique - Processamento de Análises: Kafka Streams ou Flink para agregação em tempo real - Geração de ID: Serviço de alocação baseado em faixas suportado por um pequeno armazenamento de coordenação (DynamoDB ou ZooKeeper) - Monitoramento: CloudWatch, Prometheus, Grafana, PagerDuty para alertas Este projeto lida com os requisitos declarados com uma clara separação do caminho de gravação (criação de links), caminho de leitura (redirecionamentos) e caminho de análises, cada um escalável independentemente. A estratégia de cache em camadas (borda, Redis regional, local) garante que mesmo o tráfego viral extremo seja tratado graciosamente, enquanto a arquitetura multirregional com Tabelas Globais do DynamoDB fornece a durabilidade e as garantias de disponibilidade necessárias para um SLA de 99,99%.

### 1. Arquitetura de Alto Nível O sistema é projetado como uma arquitetura globalmente distribuída e multi-região para garantir baixa latência e alta disponibilidade. Cada região atua como um Ponto de Presença (PoP) autônomo. **Componentes Principais:** * **Balanceador de Carga Global (GLB):** Usa roteamento baseado em DNS (por exemplo, baseado em latência, baseado em geolocalização) para direcionar os usuários para a região saudável mais próxima. * **CDN (Rede de Distribuição de Conteúdo):** Fica na frente dos nossos servidores de aplicativos para armazenar em cache respostas de redirecionamento (HTTP 301) para links populares na borda, reduzindo drasticamente a latência e a carga em nossa infraestrutura para conteúdo viral. * **Balanceador de Carga Regional:** Distribui o tráfego dentro de uma região para os servidores web sem estado. * **Servidores Web (API Gateway):** Finalizam TLS e roteiam as solicitações para o serviço de backend apropriado. * **Serviço de Redirecionamento (Caminho de Leitura):** Um microsserviço stateless altamente otimizado que lida com solicitações `GET /{short_id}`. Ele realiza uma consulta (primeiro cache, depois banco de dados) e emite um redirecionamento. Este é o componente mais crítico e de maior tráfego. * **Serviço de Links (Caminho de Escrita):** Um microsserviço que lida com `POST /api/v1/links` para criar novos links curtos. Ele coordena com o Gerador de IDs e grava no banco de dados. * **Serviço de Análise:** Um microsserviço que fornece dados de análise via `GET /api/v1/links/{short_id}/analytics`. Ele lê de um armazenamento de dados de análise dedicado. * **Serviço Gerador de IDs:** Um serviço dedicado (por exemplo, baseado em Snowflake) que gera IDs de 64 bits globalmente exclusivos e aproximadamente ordenáveis por tempo para serem usados em links curtos. * **Fila de Mensagens (por exemplo, Kafka, AWS SQS):** Desacopla o caminho de redirecionamento crítico do processamento não crítico de análises. O Serviço de Redirecionamento publica um evento de clique leve na fila para cada redirecionamento bem-sucedido. * **Processador de Ingestão de Análise:** Um serviço consumidor que lê da fila de mensagens, processa eventos de clique e atualiza o armazenamento de dados de análise e os contadores agregados. *(Link para o diagrama conceitual)* ### 2. Modelo de Dados e Escolhas de Armazenamento Usaremos dois armazenamentos de dados separados, otimizados para seus padrões de acesso específicos. **A. Armazenamento de Mapeamento de Links** * **Escolha:** Um banco de dados NoSQL distribuído de chave-valor como **Amazon DynamoDB** com Tabelas Globais ou **Apache Cassandra**. * **Justificativa:** Essa escolha é impulsionada pela necessidade de escalabilidade massiva, alta disponibilidade e consultas de baixa latência baseadas em chave. O padrão de leitura principal é uma consulta direta por `short_id`, que se encaixa perfeitamente em um modelo de chave-valor. Uma configuração multi-região e multi-master (como Tabelas Globais do DynamoDB) fornece leituras e gravações de baixa latência para usuários globais e recuperação de desastres integrada. * **Esquema (tabela `links`): * `short_id` (String, Chave de Partição): O código exclusivo de 7 caracteres ou alias personalizado. * `long_url` (String): A URL de destino. * `created_at` (Timestamp): Timestamp de criação. * `total_clicks` (Number): Um contador atômico para cliques totais vitalícios, atualizado pelo processador de análise. **B. Armazenamento de Dados de Análise** * **Escolha:** Um banco de dados de colunas largas ou séries temporais como **Apache Cassandra** ou **Amazon Timestream**. * **Justificativa:** Este armazenamento precisa lidar com uma taxa de transferência de gravação muito alta de eventos de clique e consultar eficientemente dados por intervalo de tempo (por exemplo, últimos 30 dias). Um armazenamento de colunas largas nos permite modelar isso de forma eficaz. * **Esquema (tabela `clicks_by_day`): * `short_id` (String, Chave de Partição): O identificador do link. * `event_date` (String, Chave de Clusterização, formato `AAAA-MM-DD`): A data dos cliques. * `daily_count` (Counter): Um contador distribuído para o número de cliques naquele dia. Este modelo pré-agregado é eficiente para a consulta necessária ("cliques por dia"). Dados brutos de eventos poderiam ser armazenados em um armazenamento de objetos mais barato (como S3) para arquivamento de longo prazo, se necessário. ### 3. Estratégia de Geração de IDs * **IDs Gerados:** Precisamos de IDs curtos, exclusivos e não sequenciais. Uma string de 7 caracteres usando codificação Base62 (`[a-zA-Z0-9]`) fornece 62^7 (~3,5 trilhões) combinações exclusivas, o que é mais do que suficiente para os 7,2 bilhões de links esperados ao longo de 5 anos. 1. O **Serviço Gerador de IDs** produz um inteiro de 64 bits globalmente exclusivo (semelhante ao Snowflake do Twitter), que combina um timestamp, um ID de região/máquina e um número de sequência. Isso evita um único ponto de falha e contenção. 2. O **Serviço de Links** solicita um ID do gerador. 3. Em seguida, ele codifica em Base62 o inteiro de 64 bits para criar a string `short_id`. * **Aliases Personalizados:** 1. Quando um usuário envia um alias personalizado, o Serviço de Links realiza uma leitura direta na tabela `links` usando o alias como chave. 2. Se a chave não existir, ele prossegue para gravar a nova entrada usando uma gravação condicional (por exemplo, `put if not exists`) para evitar condições de corrida onde dois usuários reivindicam o mesmo alias simultaneamente. 3. Se a chave existir, ele retorna um erro 409 Conflict. ### 4. Design da API O serviço expõe uma API RESTful simples. * **Criar Link Curto:** `POST /api/v1/links` * **Corpo da Solicitação:** `{"long_url": "https://example.com/very/long/path", "custom_alias": "my-link"}` (custom_alias é opcional) * **Sucesso (201 Created):** `{"short_url": "https://sho.rt/my-link", "long_url": "..."}` * **Erro (409 Conflict):** Se o alias personalizado já estiver em uso. * **Redirecionar Usuário:** `GET /{short_id}` * **Exemplo:** `GET /aB1x2Yc` * **Sucesso (301 Moved Permanently):** `Location: https://example.com/very/long/path` * **Erro (404 Not Found):** Se o `short_id` não existir. * **Obter Análises:** `GET /api/v1/links/{short_id}/analytics` * **Sucesso (200 OK):** `{"short_id": "aB1x2Yc", "total_clicks": 15023, "daily_clicks": [{"date": "2023-10-27", "clicks": 850}, {"date": "2023-10-26", "clicks": 1200}]}` ### 5. Cache, Particionamento e Replicação * **Cache:** Uma estratégia de cache de várias camadas é essencial para lidar com tráfego com muitas leituras e hotspots virais. 1. **Cache CDN:** A CDN armazena em cache respostas de redirecionamento `301` na borda. Esta é a primeira linha de defesa e lida com a maior parte do tráfego para links populares. 2. **Cache em Memória:** Cada região possui um cache distribuído (por exemplo, **Redis Cluster**) que armazena mapeamentos `short_id -> long_url`. O Serviço de Redirecionamento segue um padrão de leitura direta (read-through): verifica o Redis primeiro e, em caso de falha, consulta o banco de dados e preenche o cache com um TTL (por exemplo, 24 horas). 3. **Cache Negativo:** Armazena em cache resultados de "não encontrado" por um curto período (por exemplo, 5 minutos) para evitar consultas repetidas ao banco de dados para links inválidos ou excluídos. * **Particionamento:** Os bancos de dados NoSQL (DynamoDB/Cassandra) particionam automaticamente os dados com base no hash do `short_id`. Isso distribui os dados e a carga de I/O horizontalmente pelo cluster, permitindo escala massiva. * **Replicação:** O banco de dados principal de `links` é replicado em todas as regiões ativas em uma configuração multi-master. Isso garante que um link criado em uma região esteja rapidamente disponível para redirecionamento em todas as outras regiões, fornecendo leituras de baixa latência globalmente e alta durabilidade de dados. ### 6. Confiabilidade e Escalabilidade * **Confiabilidade:** * **Ativo-Ativo Multi-Região:** Toda a pilha é implantada em pelo menos três regiões geograficamente separadas. O GLB realiza verificações de integridade e roteará automaticamente o tráfego para longe de qualquer região com falha, permitindo que o serviço sobreviva a uma interrupção regional completa. * **Serviços Stateless:** Todos os serviços (Redirecionamento, Link, Análise) são stateless, permitindo que sejam escalados horizontalmente e substituídos facilmente se uma instância falhar. * **Desacoplamento:** A fila de mensagens garante que uma lentidão ou falha no pipeline de análise não afete a funcionalidade crítica de redirecionamento voltada para o usuário. * **Escalabilidade para Tráfego de Leitura:** 1. **CDN:** A CDN absorve a maioria das solicitações para links virais. 2. **Escalabilidade Horizontal:** O Serviço de Redirecionamento stateless pode ser escalado adicionando mais instâncias atrás do balanceador de carga regional. 3. **Escalabilidade do Cache:** O cache distribuído pode ser escalado adicionando mais nós ao cluster. 4. **Escalabilidade do Banco de Dados:** O banco de dados NoSQL particionado escala adicionando mais nós. ### 7. Principais Compromissos (Trade-offs) * **Consistência vs. Disponibilidade:** Priorizamos a Disponibilidade sobre a Consistência Forte. O uso de um banco de dados multi-master significa que conflitos de gravação são possíveis (embora raros para este caso de uso). A consistência eventual é aceitável para a propagação de links entre regiões e é necessária para os dados de análise (atraso de até 10 minutos). * **Custo vs. Desempenho:** Uma arquitetura global, multi-região, ativo-ativo com CDN e múltiplos armazenamentos de dados é cara. No entanto, é necessária para atender aos rigorosos requisitos de 99,99% de disponibilidade e baixa latência global. Um design de região única mais barato não seria suficiente. * **Complexidade Operacional:** A arquitetura de microsserviços adiciona complexidade em termos de implantação, monitoramento e manutenção em comparação com um monólito. Essa troca é feita para alcançar escalabilidade independente, isolamento de falhas e resiliência para diferentes partes do sistema.