Edge POPs vs roteamento apenas por DNS: o tradeoff de orçamento de latência

O orçamento de latência para um redirecionamento de URL tem dois regimes. Abaixo de ~50ms p50, você está no território de edge POP - anycast roteia o usuário para um cache próximo, o redirecionamento responde antes que o handshake TCP pareça caro. Acima de ~50ms, você está no território apenas de DNS - o balanceamento de carga baseado em DNS roteia o cliente no momento da resolução de nomes, o redirecionamento é uma única viagem de ida e volta TCP entre continentes, e o orçamento inclui essa viagem. As arquiteturas parecem superficialmente semelhantes (ambas servem um 302). Os envelopes de desempenho não são os mesmos. Este post é a comparação.

Para o post fundamental sobre orçamento de latência, atingir p95 < 15ms para redirecionamentos é a leitura longa. Este post trata da decisão arquitetural por trás disso.

O que "roteamento apenas por DNS" realmente significa

O roteamento apenas por DNS responde à pergunta "qual origem este cliente deve atingir?" com a resolução DNS, não com o caminho TCP. Um usuário em Sydney resolve r.exemplo.com e o provedor DNS (roteamento baseado em latência do Route 53, GeoDNS no Cloudflare, NS1, etc.) retorna o IP da origem mais próxima - digamos, a instância em Sydney do seu serviço de redirecionamento.

A arquitetura:

Cliente (Sydney) ──consulta DNS── DNS Autoritativo
       │                                │
       │  retorna IP do pod Sydney      │
       ↓
   Origem Sydney ──redirect 302──→ Cliente

O provedor DNS não vê a requisição HTTP real. Ele só vê a consulta do resolver - e esse resolver pode estar a um país de distância, caso em que "mais próximo" se torna uma suposição. A própria requisição HTTP é uma viagem de ida e volta para a origem escolhida.

Custo de viagem de ida e volta. O caminho mais rápido é um handshake TCP + uma troca HTTP para a origem mais próxima. Se a origem mais próxima está a 40ms de distância (Sydney → local em Sydney), o redirecionamento resolve em ~60-80ms no relógio de parede (handshake + requisição + resposta).

Modo de falha. Quando a origem escolhida está fora do ar, os TTLs do DNS se tornam o gargalo. Um TTL de 60 segundos significa que os clientes podem levar até um minuto para descobrir a falha e tentar novamente com um IP diferente. A cadência de verificação de integridade do provedor DNS define a janela de recuperação real.

O que "roteamento por edge POP" realmente significa

O roteamento por edge POP coloca uma frota de servidores de cache em muitas regiões, todos respondendo no mesmo IP anycast. O primeiro pacote do cliente para esse IP é roteado pelo BGP para o POP topologicamente mais próximo - não mais próximo em distância geográfica, mas mais próximo no sentido de rede (menos saltos de roteador, menor latência medida).

A arquitetura:

Cliente (Sydney) ──pacote para IP anycast── POP mais próximo pelo BGP (Singapura)
                                                  │
                                      Cache hit? responder 302
                                                  │
                                      Cache miss → origem (Frankfurt)
                                      Cache → responder 302

O POP mais próximo pelo BGP serve o redirecionamento a partir do cache. Os cache hits ignoram completamente a origem. Os cache misses são infrequentes (o primeiro miss de um link populares após o deploy; o deploy invalida uma linha por slug, não o cache inteiro).

Custo de viagem de ida e volta. Um cache hit responde em 5-15ms no relógio de parede (handshake TCP para o POP local, resposta imediata). Um cache miss adiciona uma viagem de ida e volta entre continentes de ~80-150ms para a origem - mas essa viagem acontece uma vez, depois a linha fica em cache no POP para a próxima requisição.

Modo de falha. Quando um POP falha, o BGP retira o prefixo. O próximo pacote do cliente vai automaticamente para o próximo POP mais próximo. A recuperação é sub-segundo, não sub-minuto.

Os quatro números que decidem qual arquitetura se encaixa

1. Seu número de origens. Se você tem uma origem (implantação de região única), o roteamento DNS não pode ajudar - não há nada entre o que rotear. Os POPs anycast adicionam valor ao frontear a origem única com caches.

2. Sua taxa de acerto de cache. Os edge POPs só são rápidos quando o cache responde. Os encurtadores de URL têm taxas de acerto de 95%+ - o mapa slug-para-destino é pequeno e dominado por leituras. Se a taxa de acerto do seu workload estiver abaixo de 50%, os edge POPs degradam para "salto extra antes da origem" e o roteamento DNS é a arquitetura mais limpa.

3. Sua distribuição geográfica. Se seus usuários são 90%+ em um único país, ambas as arquiteturas têm desempenho semelhante - uma origem naquele país já está a menos de 30ms de todos. Se seus usuários estão distribuídos por continentes, a arquitetura de edge POP começa a ganhar. Um usuário em Sydney atingindo uma origem apenas em Frankfurt via roteamento DNS paga o RTT intercontinental (~180-220ms handshake TCP) em cada redirecionamento. Com um edge POP em Singapura, esse mesmo usuário paga ~25ms.

4. Sua tolerância a falhas com propagação lenta. A recuperação baseada em DNS é limitada pelo cache de TTL do resolver mais lento. Alguns resolvers não respeitam TTLs baixos; eles limitam o TTL mínimo a 60 ou 300 segundos. Se o seu encurtador de URL ocasionalmente precisa colocar uma origem offline (deploy, manutenção, região fora do ar), o roteamento DNS deixa uma longa cauda de clientes na origem morta. O anycast retira em sub-segundo.

Plote os quatro números em relação a um workload típico de encurtador de URL:

• Contagem de origens: tipicamente 2-3 (multi-região para redundância)
• Taxa de acerto de cache: 95-99% (o mapa de slugs é pequeno)
• Distribuição geográfica: tipicamente multi-continental (qualquer marca voltada ao consumidor)
• Tolerância a falhas: zero (o link está em materiais impressos; o tempo de inatividade custa confiança)

Todos os quatro apontam para edge POPs. A arquitetura apenas de DNS é mais apropriada para ferramentas internas de SaaS B2B onde a superfície de redirecionamento é regional e o mapa de slugs muda frequentemente (mais invalidações de cache do que leituras).

Como os números de latência realmente se parecem

Avaliamos ambas as arquiteturas de quatro locais em relação ao mesmo workload (link curto único, cache frio depois cache quente). Os números abaixo são p50 / p95 de 1000 requisições sequenciais por local.

Roteamento apenas por DNS (origem única em Frankfurt, roteamento GeoDNS):

Localização da origem	Cliente → Frankfurt	p50	p95
Frankfurt	<1ms	4ms	9ms
Londres	14ms	22ms	35ms
Nova York	90ms	110ms	145ms
Singapura	165ms	195ms	240ms

Roteamento por edge POP (anycast em FRA, ASH, SGP), cache HIT:

Localização do cliente	Roteia para POP	p50	p95
Frankfurt	FRA	3ms	7ms
Londres	FRA	11ms	18ms
Nova York	ASH	5ms	9ms
Singapura	SGP	4ms	8ms

A diferença está nos locais de cauda longa. Frankfurt parece semelhante em ambos porque é a origem no caso apenas de DNS. Singapura é o mais dramático: de p50 195ms para p50 4ms, porque a arquitetura de edge POP responde a partir de Singapura diretamente. A arquitetura apenas de DNS paga a viagem de ida e volta intercontinental em cada redirecionamento, independentemente do cache.

Tradeoff de custo

Os edge POPs custam mais por redirecionamento em baixo volume. O custo fixo de executar um POP - mesmo um pequeno em um servidor Hetzner Falkenstein - é real. Em menos de 100 mil redirecionamentos/mês, o roteamento apenas de DNS contra uma única origem é mais barato.

O ponto de cruzamento está em torno de 1 milhão de redirecionamentos/mês. Acima disso, a arquitetura de edge POP vence no custo por redirecionamento porque as respostas de cache hit não tocam o processamento ou a largura de banda da origem. A origem escala para preenchimentos de cache (~1% das requisições) em vez de para o volume total de requisições.

A maioria dos encurtadores de URL está acima do ponto de cruzamento desde o primeiro dia porque a distribuição do workload tem cauda pesada - alguns links populares carregam a maior parte do volume de cliques, e esses links têm taxas de acerto de cache efetivamente infinitas.

O que os edge POPs não corrigem

Os edge POPs não são uma atualização universal. Três workloads em que eles tornam as coisas mais lentas, não mais rápidas:

1. Escritas. Criar um novo link, atualizar um destino - esses têm que chegar à origem autoritativa e depois se propagar para a camada de invalidação de cache. A latência de leitura é ótima; a latência de escrita é aproximadamente a mesma que o caminho apenas de origem.

2. Redirecionamentos personalizados. Links inteligentes que roteiam por identidade do usuário (não apenas por slug) não podem ser armazenados em cache no POP - eles precisam atingir a origem toda vez para ler o perfil do usuário. O POP se torna um proxy fino apenas para terminação TLS, adicionando 5-10ms ao que de outra forma seria um acesso direto à origem. Para a maioria dos encurtadores de URL, isso é aceitável porque os redirecionamentos personalizados são uma pequena minoria do tráfego. Para produtos de deep linking (Branch, Adjust), a taxa de personalização está mais próxima de 50%, o que muda os cálculos de arquitetura.

3. Destinos com restrição geográfica. Se o destino do redirecionamento muda por localização geográfica do usuário (página de destino diferente por país), a chave de cache precisa incluir o país. Isso fragmenta o cache - em vez de uma linha por slug, você tem N linhas por slug para N países suportados. A taxa de acerto de cache cai; o custo de memória de cache aumenta. Os POPs ainda ajudam, apenas menos.

Para encurtadores de URL, o terceiro caso é o que deve ser monitorado. A maioria dos links curtos resolve para uma URL independentemente da localização geográfica do usuário, portanto, uma única chave de cache funciona. Mas assim que você adiciona variantes por país, a equação de custo muda.

Como o Elido faz isso

Três POPs (Hetzner Falkenstein, Hetzner Ashburn, OVH Singapura), anycast sobre um /24 que possuímos. Caddy na borda para TLS + certificados sob demanda; fasthttp atrás do Caddy para o redirecionamento em si. Cache de dois níveis: LRU em processo (L1, ~10 mil slugs mais populares em memória) → Redis Cluster (L2, conjunto completo de slugs). Cache miss passa para o endpoint gRPC do api-core, que lê do Postgres.

Cadência de preenchimento de cache: qualquer atualização no destino de um link publica um evento de invalidação no Redpanda. Os edge POPs se inscrevem e descartam sua entrada L1 para o slug afetado. A próxima requisição para esse slug atinge o L2 (ainda quente) e popula o L1. A latência de invalidação p95 é ~120ms nos três POPs.

Esta arquitetura é o post fundamental p95 de redirecionamento < 15ms em detalhe operacional. O documento de arquitetura em /docs/architecture/edge-redirect tem o diagrama completo.

A árvore de decisão

Uma lista de verificação rápida se você está escolhendo entre arquiteturas apenas de DNS e edge POP:

• Base de usuários em único país + origem única? Apenas DNS está bem. Não exagere na engenharia.
• Usuários em múltiplos países + alta taxa de acerto de cache? Edge POPs. O ganho de latência é dramático em locais de cauda longa.
• Usuários em múltiplos países + redirecionamentos personalizados em mais de 50% do tráfego? Misto. Os POPs ajudam com a terminação TLS, mas não com o redirecionamento em si. Considere roteamento DNS + uma pequena frota de POPs apenas para terminação SSL.
• SLA estrito na velocidade de failover? Edge POPs vencem - a retirada BGP supera o cache de TTL DNS por ordens de magnitude.
• Menos de 1 milhão de redirecionamentos/mês? Apenas DNS é mais barato. Reavalie em 1 milhão+.

Não há uma resposta que sirva para todos. Os encurtadores de URL especificamente tendem a se encaixar no grupo "multi-país + alta taxa de acerto de cache + SLA de failover estrito", o que é por isso que a maioria dos encurtadores de URL em produção eventualmente migra para uma arquitetura de edge POP. O custo de transição (rearquitetura do preenchimento de cache, escolha de provedores de POP, configuração BGP) é real, mas limitado.

Relacionados no blog

• Atingindo p95 < 15ms para redirecionamentos de Frankfurt, Ashburn e Singapura - post fundamental, com o detalhe operacional
• Estratégia de cache para redirecionamentos de URL: o que evitar e quando - a arquitetura de cache L1/L2
• Ingestão de cliques fire-and-forget - o que acontece no caminho de redirecionamento que não é a consulta de cache
• Por que ClickHouse para analytics de cliques (e não Postgres) - o lado analítico da mesma arquitetura
• Links curtos como Terraform: o post fundamental de engenharia - IaC para gerenciar a configuração de borda