Projetar um serviço de encurtamento de URL

A) Design da API

1. Criar URL curta

• Endpoint: POST /v1/urls
• JSON de Requisição:
  • long_url (string, obrigatório, máx. ex: 8KB)
  • custom_alias (string, opcional; se fornecido deve ser único e passar no charset/comprimento permitidos)
  • expire_at (timestamp, opcional)
  • metadata (object, opcional: ex: campanha, user_id)
• Resposta (201):
  • code (string)
  • short_url (string)
  • long_url (string)
  • created_at (timestamp)
  • expire_at (timestamp|null)
• Erros:
  • 400 URL/alias inválido
  • 409 alias já existe
  • 429 rate limited

2. Resolver/redirecionar

• Endpoint: GET /{code}
• Comportamento:
  • 301 Movido Permanentemente por padrão (ou 302 se rastreamento/experimentação exigir)
  • Cabeçalho Location = long_url
• Opcional: GET /v1/urls/{code} retorna JSON em vez de redirecionamento (para clientes API)
• Erros:
  • 404 não encontrado/expirado

3. Excluir/desativar (opcional, para controle de abuso/usuário)

• Endpoint: DELETE /v1/urls/{code}
• Autenticação necessária
• Resposta: 204

4. Análises (opcional, pode ser assíncrono/aproximado)

• Endpoint: GET /v1/urls/{code}/stats?from=&to=
• Retorna contadores agregados (cliques por dia, referenciador, geo, etc.)

Notas:

• Autenticação: Chaves de API/OAuth para criação e gerenciamento; redirecionamentos permanecem públicos.
• Idempotência: suporta cabeçalho Idempotency-Key no POST para evitar duplicatas em novas tentativas.

B) Modelo de Dados e Armazenamento

Carga de Trabalho

• Gravações: 100M novas/mês ≈ 3,33M/dia ≈ 38,6 gravações/segundo em média (pico mais alto).
• Leituras: 100:1 => 10B redirecionamentos/mês ≈ 3,86K leituras/segundo em média (picos muito mais altos).

Escolha de Armazenamento

• Armazenamento principal: store distribuído de chave-valor / coluna larga (ex: DynamoDB/Cassandra/ScyllaDB) otimizado para QPS de leitura muito alta, baixa latência, escalonamento horizontal e replicação multi-DC.
• Racional: o padrão de acesso é principalmente consulta por chave usando código curto; o valor é pequeno; forte necessidade de alta disponibilidade e latência previsível.
• Sistemas secundários:
  • Cache: clusters Redis/Memcached por região.
  • Pipeline de análise: Kafka/PubSub + processamento de fluxo + store OLAP (não no caminho crítico).

Esquema

1. url_mapping (principal)

• Chave de partição: code (string)
• Colunas:
  • long_url (string)
  • created_at (timestamp)
  • expire_at (timestamp|null)
  • user_id (string|null)
  • status (ativo/excluído)
  • checksum (opcional para integridade)
• TTL: se expire_at definido, use TTL nativo para que entradas expiradas sejam removidas automaticamente.

2. alias_reservation (opcional se suportar aliases personalizados com exclusividade)

• chave: custom_alias
• valor: code / metadados de propriedade

3. idempotency (opcional)

• chave: (user_id, idempotency_key)
• valor: code
• TTL: ex: 24h

Estimativa de Armazenamento (10 anos)

• Novos URLs em 10 anos: 100M/mês * 12 * 10 = 12B mapeamentos.
• Tamanho aproximado por registro:
  • code: ~8 bytes (ou até ~10 caracteres)
  • long_url: assume média de 200 bytes (conservador), mais sobrecarga
  • sobrecarga de metadados/colunas/índice: assume ~100–200 bytes dependendo do store
  • Total efetivo (incluindo sobrecarga de replicação ainda não contada): ~400 bytes/registro (figura razoável para planejamento).
• Dados brutos: 12B * 400B = 4,8 TB.
• Com sobrecarga do motor de armazenamento + compactação + índices secundários: planeje ~2–3x => ~10–15 TB.
• Replicação:
  • Dentro da região (RF=3): ~30–45 TB.
  • Multi-região (ex: 2 regiões ativo-ativo): dobre => ~60–90 TB no total em todas as regiões.
    (Estes são números de planejamento; o exato depende do comprimento médio do URL e da sobrecarga do DB.)

C) Geração de URL Curta

Objetivos

• O mais curto possível
• Livre de colisões em alta escala
• Suporta pelo menos 10 anos de crescimento

Matemática do Espaço de Chaves

• Códigos totais necessários em 10 anos: 12B.
• Use o charset Base62: [0-9][a-z][A-Z] => 62 símbolos.
• Capacidade de comprimento L: 62^L.
  • 62^6 ≈ 56,8B (suficiente para 12B)
  • 62^7 ≈ 3,52T (mais margem)

Escolha

• Use comprimento variável com um mínimo de 6 caracteres.
• Comece com 6 caracteres para os primeiros ~56,8B códigos; isso já cobre o requisito de 10 anos com margem significativa (56,8B/12B ≈ 4,7x).
• Mantenha a capacidade de mudar para 7 caracteres no futuro sem quebrar links existentes.

Algoritmo de Geração (sem colisões)
Opção selecionada: IDs numéricos globalmente únicos + codificação Base62.

• Mantenha um espaço de ID de 64 bits monotonicamente crescente.
• Codifique o ID em Base62 para produzir o código.
• Evitar colisões: nenhuma necessidade, pois os IDs são únicos por construção.

Como gerar IDs em escala

• Use um alocador de ID distribuído semelhante ao Snowflake, ou um "serviço de ID" central com concessão de intervalos:
  1. O serviço de ID armazena um contador em um store fortemente consistente (ex: etcd/Spanner) por região.
  2. Cada servidor de aplicativo obtém um bloco de ID (ex: 1M IDs) para gerar localmente.
  3. Quando o bloco se esgota, solicita um novo bloco.
• Isso evita contenção por gravação, garantindo a exclusividade.

Tratamento de aliases personalizados

• Se custom_alias fornecido:
  • Valide charset/comprimento
  • Gravação condicional (compare-and-set) em url_mapping com chave=alias; se existir, retorne 409.

D) Escalabilidade e Desempenho

Arquitetura de alto nível

• Anycast/GeoDNS -> Balanceador de Carga Global -> Balanceadores de Carga L7 Regionais -> servidores de API/redirecionamento sem estado.
• Serviços separados:
  • Caminho de gravação: serviço de criação de URL
  • Caminho de leitura: serviço de redirecionamento
  • Armazenamento compartilhado + cache

Escalando leituras e gravações independentemente

• Serviço de redirecionamento escalado horizontalmente com base em QPS/latência (provavelmente o custo dominante).
• Serviço de criação escalado com base na taxa de transferência de gravação.
• Use grupos de autoescalonamento separados e pipelines de implantação independentes.

Particionamento de dados

• Particione por hash de código (ou pelo próprio código) entre os nós do DB.
• Distribuição uniforme porque os códigos são efetivamente uniformes no espaço de IDs quando codificados em Base62.

Estratégia de Cache

• Principal: cache de CDN/borda para redirecionamentos + cache em memória regional.
  1. CDN:
     • Cache de respostas 301/302 com chave pelo caminho (código) com TTL (ex: 5–60 minutos, ou respeitar expire_at).
     • Para links extremamente populares, a CDN pode absorver a maior parte do tráfego globalmente.
  2. Cache Regional (Redis/Memcached):
     • Chave: code
     • Valor: long_url + expire_at + status
     • TTL: min(default_ttl, expire_at-now)
     • Evicção: LRU ou LFU (preferir LFU para popularidade enviesada).

Taxa de acerto esperada

• Acessos a URLs são tipicamente altamente enviesados (Zipf). Com CDN + cache regional, uma taxa de acerto de 95–99% é viável para redirecionamentos; mesmo 90% é útil.
• Aquecimento de cache: na gravação, envie o mapeamento para o cache; também cache negativo para falhas (TTL curto) para reduzir acertos repetidos no DB para códigos inválidos.

Atendendo à latência de redirecionamento p95 <50ms

• Caminho crítico para acerto em cache:
  • Acerto de Edge/CDN: frequentemente <20ms.
  • Acerto de cache regional: LB + app + consulta Redis + resposta: tipicamente 5–15ms dentro da região.
• Para falha de cache:
  • Leitura única do DB de uma réplica local da região: alvo 5–20ms.
• Mantenha os servidores de redirecionamento próximos aos usuários via multi-região + borda.
• Use keep-alive, HTTP/2 entre componentes, pool de conexões para Redis/DB.
• Evite análises síncronas; emita eventos de clique assincronamente para uma fila.

Desempenho de Gravação

• Gravações são baixas em comparação com leituras; ainda assim, lide com rajadas.
• Fluxo de gravação:
  1. Gerar ID/código
  2. Gravar no DB (quorum/maioria dentro da região)
  3. Gravação direta no cache
  4. Retornar resposta
• Opcional: deduplicar long_url idêntico armazenando um índice hash->código (trade-off; veja F).

E) Confiabilidade e Tolerância a Falhas

Meta de disponibilidade: 99,9%

• Multi-AZ dentro de cada região para todos os componentes com estado.
• Pelo menos duas regiões ativo-ativo para tráfego de redirecionamento.

Estratégia de Replicação

• Dentro da região: fator de replicação 3 entre AZs.
• Entre regiões:
  • Replicação assíncrona para url_mapping para manter a latência de gravação baixa e a disponibilidade alta.
  • Redirecionamentos servidos da região local; se o mapeamento local estiver ausente devido a atraso na replicação, fallback para outra região (veja abaixo).

Tratamento de falha de data center/região (degradação graciosa)

• Use verificações de integridade do Balanceador de Carga Global:
  • Se uma região estiver indisponível, direcione o tráfego para a próxima região saudável mais próxima.
• Para solicitações de redirecionamento:
  • Se o cache/DB regional estiver degradado, o serviço de redirecionamento pode:
    1. Tentar o cache
    2. Tentar o DB local
    3. Se o DB local estiver indisponível, consulte um endpoint de leitura de região remota (com timeout estrito) ou use uma réplica de leitura entre regiões.
    4. Se tudo falhar, retorne um 503 rápido com Retry-After (falha graciosa).
• Para solicitações de gravação:
  • Prefira gravações na região local; se a região estiver inativa, faça failover para outra região.
  • Alocação de ID: cada região tem seu próprio namespace de bloco de ID (ou usa bits de região no Snowflake) para evitar conflitos durante o failover.

Compromisso do teorema CAP

• Escolha Disponibilidade sobre Consistência forte para operações globais:
  • Redirecionamentos devem ser altamente disponíveis; leituras desatualizadas são aceitáveis brevemente.
  • Replicação entre regiões é assíncrona: um URL curto recém-criado pode não ser resolvido em outra região por uma pequena janela.
    Mitigações:
  • Após a criação, retorne um URL curto hospedado no mesmo domínio da região (ou use borda que direcione para a região de origem nos primeiros minutos).
  • Na criação, opcionalmente faça uma gravação síncrona em duas regiões para clientes premium/enterprise (maior latência/custo).

Backups e recuperação de desastres

• Snapshots periódicos + backups incrementais para armazenamento de objetos.
• Exercícios de restauração regulares.

F) Discussão de Trade-offs

1. Geração de código baseada em ID vs tokens aleatórios

• Escolhido: baseado em ID (intervalo alugado/Snowflake) + Base62.
• Ganhos:
  • Sem colisões, sem necessidade de loops de repetição.
  • Planejamento de capacidade previsível e restrições de DB mais simples.
  • Gravações mais rápidas.
• Sacrifícios:
  • Códigos são adivinháveis/sequenciais (segurança por obscuridade não fornecida).
    Mitigação:
  • Adicione "permução com salt" opcional (ex: rede Feistel) sobre o ID numérico antes da codificação Base62 para tornar os códigos não sequenciais, preservando a exclusividade.

2. Replicação entre regiões assíncrona (AP) vs multi-região síncrona (CP)

• Escolhido: replicação entre regiões assíncrona.
• Ganhos:
  • Menor latência de gravação, maior disponibilidade durante falhas parciais.
  • Melhor capacidade de continuar servindo redirecionamentos mesmo se uma região estiver prejudicada.
• Sacrifícios:
  • Consistência eventual: janela breve onde um URL recém-criado pode não ser legível em outra região.
    Mitigação:
  • Reparo de leitura/fallback para região de origem para links recentes; gravação dupla opcional para clientes com alto SLA.

3. Cache pesado/CDN vs sempre atingir o DB

• Escolhido: CDN + cache regional.
• Ganhos:
  • Facilmente atende a p95 <50ms e reduz drasticamente a carga do DB.
  • Lida com picos de tráfego para links virais.
• Sacrifícios:
  • Complexidade de invalidação de cache (ex: links excluídos/expirados).
    Mitigação:
  • TTLs curtos, respeitar expire_at e purga explícita na exclusão para CDN onde suportado; usar flags de status e cache negativo com cuidado.

A) Design de API:

1. Endpoint para Encurtar URL:

   • Método: POST
   • Caminho: /shorten
   • Corpo da Requisição (JSON):

     {
       "long_url": "string",
       "custom_short_code": "string" (opcional),
       "expires_at": "string de data/hora no formato ISO 8601" (opcional)
     }
     

   • Corpo da Resposta (JSON - 201 Created):

     {
       "short_url": "string",
       "long_url": "string",
       "custom_short_code": "string" (se fornecido),
       "expires_at": "string de data/hora no formato ISO 8601" (se fornecido)
     }
     

   • Respostas de Erro:
     • 400 Bad Request: Formato de long_url inválido ou ausente.
     • 409 Conflict: custom_short_code já existe.
     • 500 Internal Server Error: Erro geral do servidor.

2. Endpoint para Redirecionar URL Curta:

   • Método: GET
   • Caminho: /{shortCode}
   • Resposta: Redirecionamento HTTP 302 Found para o long_url.
   • Respostas de Erro:
     • 404 Not Found: shortCode não existe ou expirou.
     • 500 Internal Server Error: Erro geral do servidor.

B) Modelo de Dados e Armazenamento:

Escolha de Armazenamento: Um banco de dados relacional particionado (ex: PostgreSQL) com réplicas de leitura.

Justificativa:

• Consistência Forte para Escritas: Essencial para garantir a exclusividade dos códigos curtos. Bancos de dados relacionais fornecem propriedades ACID, cruciais para a integridade confiável dos dados durante a criação de URLs.
• Particionamento Bem Compreendido: O PostgreSQL suporta várias estratégias de particionamento (ex: baseado em intervalo, baseado em hash) para distribuir a carga de escrita e escalar horizontalmente.
• Indexação Eficiente: Índices B-tree são altamente eficientes para buscas pontuais em short_code, que é a operação primária para redirecionamentos.
• Réplicas de Leitura: Suporta facilmente a escalabilidade de operações de leitura (redirecionamentos) adicionando várias réplicas somente leitura.
• Maturidade e Ecossistema: Ferramentas robustas para monitoramento, backup e recuperação.

Esquema:

urls Tabela:

• id: BIGINT, Chave Primária, Auto-incremento (ou gerado por um serviço de ID distribuído). Usado como base para o código curto.
• short_code: VARCHAR(7), Índice Único, NÃO NULO. A string curta real usada na URL.
• long_url: TEXT, NÃO NULO. A URL longa original.
• created_at: TIMESTAMP WITH TIME ZONE, NÃO NULO, Padrão: NOW().
• expires_at: TIMESTAMP WITH TIME ZONE (nulo). Quando a URL curta deve expirar.
• user_id: BIGINT (nulo, chave estrangeira para uma tabela users se contas de usuário forem suportadas).

Estimativa de Armazenamento (ao longo de 10 anos):

• Volume: 100 milhões de novas URLs/mês * 12 meses/ano * 10 anos = 12 bilhões de URLs.
• Estimativa de Tamanho do Registro:
  • id: 8 bytes (BIGINT)
  • short_code: 7 bytes (VARCHAR(7))
  • long_url: Média de 100 bytes (TEXT, comprimento variável)
  • created_at: 8 bytes (TIMESTAMP)
  • expires_at: 8 bytes (TIMESTAMP)
  • Total por registro: ~131 bytes.
• Tamanho Bruto dos Dados: 12 bilhões de registros * 131 bytes/registro = 1,572 TB.
• Com Índices e Sobrecarga: Levando em conta índices (especialmente em short_code e id), replicação e sobrecarga do banco de dados, o armazenamento total pode ser de aproximadamente 3-5 TB ao longo de 10 anos. Isso é gerenciável com uma arquitetura de banco de dados particionado.

C) Geração de URL Curta:

Algoritmo:

1. Quando uma nova requisição de encurtamento de URL chega, um ID único e monotonicamente crescente é obtido. Este ID pode ser gerado por:
   • Auto-incremento do Banco de Dados: Se estiver usando um banco de dados particionado, cada partição pode ser configurada com um intervalo de ID exclusivo (ex: partição 1 usa IDs 1, 11, 21..., partição 2 usa 2, 12, 22...).
   • Gerador de ID Distribuído: Um serviço dedicado como Snowflake (ou uma implementação personalizada semelhante) pode gerar inteiros de 64 bits globalmente únicos e ordenados por tempo.
2. Este ID único é então convertido para uma string base62. Base62 usa 62 caracteres (0-9, a-z, A-Z), o que permite uma representação compacta.

Evitação de Colisões:

• Ao derivar o código curto de um ID globalmente único (seja via auto-incremento particionado ou um gerador de ID distribuído), as colisões são inerentemente evitadas. Cada ID gerado é único, e sua representação base62 também será única.
• Para requisições de custom_short_code, o sistema tenta inserir o código fornecido pelo usuário. Se ocorrer um conflito (devido a uma entrada existente), um erro 409 Conflict é retornado ao usuário.

Conjunto de Caracteres e Comprimento:

• Conjunto de Caracteres: Base62 (0-9, a-z, A-Z) - 62 caracteres únicos.
• Comprimento: 6 caracteres inicialmente.

Justificativa Matemática para Suficiência do Espaço de Chaves:

• Volume Necessário: 12 bilhões de URLs únicas ao longo de 10 anos.
• Espaço de Chaves com 6 caracteres: 62^6 = 56.800.235.584 (aproximadamente 56,8 bilhões de códigos únicos).
• Este espaço de chaves (56,8 bilhões) é significativamente maior do que os 12 bilhões necessários, fornecendo espaço amplo para crescimento e garantindo suficiência por pelo menos 10 anos. Se o serviço exceder isso, o comprimento do código curto pode ser estendido para 7 caracteres, fornecendo 62^7 (aproximadamente 3,5 trilhões) de códigos únicos.

D) Escalabilidade e Desempenho:

Escalando Leituras (Redirecionamentos):

• Cache Distribuído (ex: Redis Cluster): O principal mecanismo de escalabilidade para leituras. Mapeamentos de short_code para long_url são armazenados em um cache distribuído e altamente disponível. Dada a proporção de 100:1 de leituras/escritas, a maioria das requisições de redirecionamento será atendida diretamente do cache.
• Réplicas de Leitura do Banco de Dados: As instâncias particionadas do PostgreSQL terão várias réplicas de leitura. Em caso de falha de cache, a requisição volta para uma réplica de leitura. Balanceadores de carga distribuem as consultas entre essas réplicas.
• Rede de Distribuição de Conteúdo (CDN): Embora não cacheie diretamente o redirecionamento 302, uma CDN pode servir ativos estáticos e potencialmente otimizar o roteamento para requisições iniciais, reduzindo a latência para usuários geograficamente dispersos.

Escalando Escritas (Encurtamentos):

• Particionamento do Banco de Dados: A estratégia principal. Os dados são particionados entre várias instâncias do PostgreSQL com base em uma chave de particionamento (ex: o id do qual o short_code é derivado). Isso distribui a carga de escrita e os requisitos de armazenamento.
• Agrupamento de Conexões: Gerencia eficientemente as conexões do banco de dados para reduzir a sobrecarga.
• Processamento Assíncrono: Para tarefas não críticas (ex: análises, logs, atualização de estatísticas), filas de mensagens (ex: Kafka, RabbitMQ) podem descarregar trabalho do caminho de escrita principal, melhorando a responsividade.

Estratégia de Cache:

• Tipo de Cache: Cache distribuído em memória (ex: Redis Cluster).
• Dados em Cache: Mapeamentos de short_code para long_url.
• Preenchimento do Cache: Em um encurtamento de URL bem-sucedido, o novo mapeamento é gravado tanto no banco de dados quanto no cache. Em uma falha de cache durante um redirecionamento, o mapeamento é buscado do banco de dados e então gravado no cache (write-through/write-aside).
• Política de Evicção: LRU (Least Recently Used) é adequado. URLs populares permanecerão no cache, enquanto as menos acessadas serão removidas para liberar espaço. Time-to-Live (TTL) também pode ser aplicado, especialmente para URLs com um campo expires_at.
• Taxa de Acerto Esperada: Dada a proporção de 100:1 de leituras/escritas e a distribuição de lei de potência do acesso a URLs (uma pequena porcentagem de URLs representa uma grande porcentagem do tráfego), uma taxa de acerto de cache de 90-95%+ é altamente alcançável, reduzindo significativamente a carga do banco de dados.

Atendendo ao Requisito de Latência p95 de 50ms:

• Alta Taxa de Acerto de Cache: A grande maioria das requisições de redirecionamento será atendida pelo cache distribuído, que pode responder em milissegundos de um único dígito.
• Acesso Otimizado ao Banco de Dados: Para falhas de cache, a indexação eficiente em short_code no banco de dados particionado garante buscas rápidas.
• Proximidade e Rede: Implantação de serviços em várias regiões próximas aos usuários e utilização de infraestrutura de rede de alta velocidade e baixa latência.
• Balanceamento de Carga: Distribuição eficiente de requisições entre instâncias de serviço saudáveis e réplicas de banco de dados.
• Servidores de Aplicação Sem Estado: Permite escalabilidade horizontal fácil da camada de API, garantindo capacidade suficiente para lidar com cargas de pico sem se tornar um gargalo.

D) Confiabilidade e Tolerância a Falhas:

Falhas de Data Center:

• Implantação Multi-Região: Todo o serviço (servidores de API, clusters de cache, partições de banco de dados) é implantado em pelo menos dois data centers/regiões geograficamente distintos.
• Balanceador de Carga Global (ex: gerenciamento de tráfego baseado em DNS): Direciona o tráfego do usuário para a região saudável mais próxima. Se uma região falhar, o tráfego é automaticamente redirecionado para a região operacional.
• Failover Automático: Clusters de banco de dados são configurados para failover automático dentro de uma região (primário para réplica) e entre regiões (configuração ativo-passivo ou ativo-ativo).

Estratégia de Replicação de Dados:

• Banco de Dados (PostgreSQL):
  • Dentro de uma Região: Replicação de streaming síncrona é usada entre a instância primária do banco de dados e suas réplicas locais. Isso garante zero perda de dados em caso de falha do primário dentro do mesmo data center.
  • Entre Regiões: Replicação de streaming assíncrona é usada da primária na região ativa para uma réplica na região passiva/standby. Isso fornece recursos de recuperação de desastres com impacto mínimo de desempenho no caminho de escrita principal. Em uma configuração ativo-ativo, a primária de cada região se replicaria assincronamente para a outra.
• Cache Distribuído (Redis Cluster): Os dados são particionados e replicados entre vários nós dentro de cada cluster Redis. Cada partição tem uma primária e pelo menos uma réplica. Em caso de falha de um nó, uma réplica é promovida a primária.

Trade-offs (Teorema CAP):

• Escolha: Priorizar Disponibilidade (A) e Tolerância a Partições (P) em vez de Consistência (C) forte para operações de leitura (redirecionamentos), mantendo consistência forte para operações de escrita (encurtamento) dentro de uma partição de banco de dados.
• Justificativa: Para um serviço de encurtamento de URL, é mais crítico que o serviço permaneça disponível e responsivo (baixa latência) mesmo durante partições de rede ou falhas de data center. Os usuários esperam que os redirecionamentos funcionem rapidamente.
• Como é alcançado:
  • Disponibilidade: Implantação multi-região, balanceamento de carga global, réplicas de leitura de banco de dados e um cache distribuído altamente disponível garantem que as requisições possam ser sempre atendidas.
  • Tolerância a Partições: A natureza distribuída do sistema (particionamento, replicação) lida inerentemente com partições de rede.
  • Consistência: Para escritas, a consistência forte é mantida dentro de uma partição de banco de dados. A replicação entre regiões é assíncrona, o que significa que pode haver uma pequena janela de inconsistência entre regiões para URLs recém-criadas. O cache também serve como uma camada de consistência eventual, pois é atualizado em escritas e em falhas de cache.

F) Discussão de Trade-offs:

1. Consistência vs. Disponibilidade para Redirecionamentos (Teorema CAP):

   • Escolha: Priorizar Disponibilidade e Tolerância a Partições em vez de Consistência Forte imediata para o caminho de redirecionamento.
   • Por quê: O objetivo principal de um encurtador de URL é fornecer redirecionamentos rápidos e confiáveis. Se uma URL recém-criada levar alguns segundos para se propagar para todas as réplicas de leitura e caches globalmente, é um inconveniente menor. No entanto, se o sistema esperar pela consistência global antes de servir um redirecionamento, isso introduziria latência significativa e reduziria a disponibilidade durante partições de rede ou falhas regionais. Os usuários preferem experimentar um 404 raro para uma URL recém-criada do que timeouts ou redirecionamentos lentos frequentes.
   • Sacrifício: Uma pequena janela de consistência eventual. Um usuário pode criar uma URL na Região A e, se imediatamente tentar acessá-la da Região B (antes que a replicação assíncrona seja concluída), ele pode temporariamente receber um 404. Em cenários extremos de falha multi-região com replicação assíncrona, há um pequeno risco de perda de dados para escritas muito recentes se a região primária falhar catastroficamente antes que a replicação para a região secundária seja concluída.
   • Ganho: Alta disponibilidade (99,9% de uptime) e latência extremamente baixa (p95 abaixo de 50ms) para a grande maioria das requisições de redirecionamento, que são as operações mais frequentes. O sistema permanece operacional e responsivo mesmo que um data center fique offline.

2. Método de Geração de Código Curto (ID Sequencial para Base62 vs. Hash da URL Longa):

   • Escolha: Gerar códigos curtos convertendo um ID único e sequencialmente crescente (de um gerador de ID distribuído ou auto-incremento particionado) para Base62.
   • Por quê: Este método garante exclusividade por design, simplificando o caminho de escrita e melhorando o desempenho. Evita as complexidades e a sobrecarga de desempenho inerentes às abordagens baseadas em hash para detecção e resolução de colisões.
   • Sacrifício: Os códigos curtos podem parecer um tanto sequenciais (ex: abcde1, abcde2) em vez de completamente aleatórios. Isso pode ser uma preocupação estética menor para alguns usuários, mas não afeta a funcionalidade. Além disso, requer um mecanismo robusto de geração de ID distribuído, o que adiciona um componente à arquitetura.
   • Ganho:
     • Exclusividade Garantida: Sem colisões, eliminando a necessidade de buscas no banco de dados e novas tentativas durante a geração do código curto, o que é crítico para alta taxa de transferência de escrita (100M/mês).
     • Caminho de Escrita Mais Simples: O processo de criação de uma nova URL curta é uma operação de inserção direta após a geração do ID.
     • Espaço de Chaves Previsível: Mais fácil de gerenciar e garantir que o espaço de chaves seja suficiente para o crescimento futuro.
     • Flexibilidade: Permite que a mesma long_url seja encurtada várias vezes, gerando diferentes short_codes, se desejado (ex: para rastrear diferentes campanhas), o que não é possível com um hash simples da long_url.