Edge POPs vs DNS-only routing: what changes the latency budget

The latency budget for a URL redirect has two regimes. Below ~50ms p50, you're in edge-POP territory — anycast routes the user to a nearby cache, the redirect responds before the TCP handshake feels expensive. Above ~50ms, you're in DNS-only territory — DNS-based load-balancing routes the client at name-resolution time, the redirect is one cross-continent TCP round trip, and the budget includes that round trip. The architectures look superficially similar (both serve a 302). The performance envelopes are not the same. This post is the comparison.

For the latency budget cornerstone, hitting p95 < 15ms for redirects is the long read. This post is the architectural decision behind it.

What "DNS-only routing" actually means#

DNS-only routing answers the question "which origin should this client hit?" with the DNS resolution, not the TCP path. A user in Sydney resolves r.example.com and the DNS provider (Route 53 latency-based routing, GeoDNS at Cloudflare, NS1, etc.) returns the IP of the closest origin — say, the Sydney instance of your redirect service.

The architecture:

Client (Sydney) ──DNS query── Authoritative DNS
       │                            │
       │  returns IP of Sydney pod  │
       ↓                            
   Sydney origin ──redirect 302──→ Client

The DNS provider doesn't see the actual HTTP request. It only sees the resolver query — and that resolver might be one country over, in which case "closest" becomes a guess. The HTTP request itself is one round trip to the chosen origin.

Round-trip cost. The fastest path is one TCP handshake + one HTTP exchange to the nearest origin. If the nearest origin is 40ms away (Sydney → Sydney-local), the redirect resolves in ~60-80ms wall-clock (handshake + request + response).

Failure mode. When the chosen origin is down, DNS TTLs become the bottleneck. A 60-second TTL means clients may take up to a minute to discover the failure and retry against a different IP. The DNS provider's health-check cadence sets the actual recovery window.

What "edge POP routing" actually means#

Edge POP routing puts a fleet of cache servers in many regions, all answering on the same anycast IP. The client's first packet to that IP gets routed by BGP to the topologically-closest POP — not closest in geographic distance, but closest in the network sense (fewest router hops, lowest measured latency).

The architecture:

Client (Sydney) ──packet to anycast IP── BGP-nearest POP (Singapore)
                                              │
                                  Cache hit? respond 302
                                              │
                                  Cache miss → origin (Frankfurt)
                                  Cache → respond 302

The BGP-nearest POP serves the redirect from cache. Cache hits skip the origin entirely. Cache misses are infrequent (a hot link's first miss after deploy; deploy invalidates one row per slug, not the whole cache).

Round-trip cost. A cache hit responds in 5-15ms wall-clock (TCP handshake to the local POP, immediate response). A cache miss adds a ~80-150ms cross-continent round trip to origin — but that round trip happens once, then the row is cached at the POP for the next request.

Failure mode. When a POP fails, BGP withdraws the prefix. The client's next packet goes to the next-closest POP automatically. Recovery is sub-second, not sub-minute.

The four numbers that decide which architecture fits#

Your origin count. If you have one origin (single-region deployment), DNS routing can't help — there's nothing to route between. Anycast POPs add value by fronting the single origin with caches.
Your cache hit ratio. Edge POPs are only fast when the cache answers. URL shorteners have hit ratios in the 95%+ range — the slug↔destination map is small and read-dominated. If your workload's hit ratio is below 50%, edge POPs degrade to "extra hop before origin", and DNS routing is the cleaner architecture.
Your geographic spread. If your users are 90%+ in one country, both architectures perform similarly — one origin in that country is already <30ms away from everyone. If your users are split across continents, the edge POP architecture starts winning. A user in Sydney hitting a Frankfurt-only origin via DNS routing pays the cross-continent RTT (~180-220ms TCP handshake) on every redirect. With an edge POP in Singapore, that same user pays ~25ms.
Your failure tolerance for slow propagation. DNS-based recovery is gated by the slowest resolver's TTL caching. Some resolvers don't honour low TTLs; they cap minimum TTL at 60 or 300 seconds. If your URL shortener occasionally needs to flip an origin offline (deploy, maintenance, region-out), DNS routing leaves a long tail of clients on the dead origin. Anycast withdraws in sub-second.

Plot the four numbers against a typical URL shortener workload:

Origin count: typically 2-3 (multi-region for redundancy)
Cache hit ratio: 95-99% (slug map is small)
Geographic spread: typically multi-continent (any consumer-facing brand)
Failure tolerance: zero (the link is in print materials; downtime costs trust)

All four push toward edge POPs. The DNS-only architecture is more appropriate for B2B SaaS internal tools where the redirect surface is regional and the slug map churns frequently (more cache invalidations than reads).

What the latency numbers actually look like#

We benchmarked both architectures from four locations against the same workload (single short link, cold-cache then warm-cache). Numbers below are p50 / p95 from 1000 sequential requests per location.

DNS-only routing (single origin in Frankfurt, GeoDNS routing):

Origin location	Client → Frankfurt	p50	p95
Frankfurt	<1ms	4ms	9ms
London	14ms	22ms	35ms
New York	90ms	110ms	145ms
Singapore	165ms	195ms	240ms

Edge POP routing (anycast across FRA, ASH, SGP), cache HIT:

Client location	Routes to POP	p50	p95
Frankfurt	FRA	3ms	7ms
London	FRA	11ms	18ms
New York	ASH	5ms	9ms
Singapore	SGP	4ms	8ms

The gap is at the long-tail locations. Frankfurt looks similar in both because it is the origin in the DNS-only case. Singapore is the dramatic one: 195ms p50 to 4ms p50, because the edge POP architecture answers from Singapore directly. The DNS-only architecture pays the cross-continent round trip on every redirect, no matter how cached.

Cost trade-off#

Edge POPs cost more per redirect at low volume. The fixed cost of running a POP — even a small one on a Hetzner Falkenstein box — is real. At <100k redirects/month, DNS-only routing against a single origin is cheaper.

The crossover is around 1M redirects/month. Above that, the edge POP architecture wins on cost-per-redirect because cache-hit responses don't touch origin compute or origin bandwidth. The origin scales for cache fills (~1% of requests) rather than for the full request volume.

Most URL shorteners are above the crossover from day-1 because the workload distribution is heavy-tailed — a few hot links carry most of the click volume, and those links have effectively infinite cache hit ratios.

What edge POPs don't fix#

Edge POPs aren't a universal upgrade. Three workloads they make slower, not faster:

Writes. Creating a new link, updating a destination — these have to land at the authoritative origin, then propagate to the cache invalidation layer. Read latency is great; write latency is roughly the same as the origin-only path.
Personalised redirects. Smart links that route on user identity (not just slug) can't be cached at the POP — they need to hit the origin every time to read the user's profile. The POP becomes a thin TLS-termination proxy, adding 5-10ms to what would otherwise be a direct origin hit. For most URL shorteners this is fine because personalised redirects are a small minority of the traffic. For deep-link products (Branch, Adjust), the personalisation rate is closer to 50%, which changes the architecture math.
Geo-restricted destinations. If the redirect destination changes by user geography (different landing page per country), the cache key has to include country. That fragments the cache — instead of one row per slug, you have N rows per slug for N supported countries. Cache hit ratio drops; cache memory cost rises. The POPs still help, just less.

For URL shorteners, the third case is the one to watch. Most short links resolve to one URL regardless of user geo, so a single cache key works. But once you add per-country variants, the cost equation shifts.

How Elido does this#

Three POPs (Hetzner Falkenstein, Hetzner Ashburn, OVH Singapore), anycast over a /24 we own. Caddy on the edge for TLS + on-demand certs; fasthttp behind Caddy for the redirect itself. Two-tier cache: in-process LRU (L1, ~10k hottest slugs in memory) → Redis Cluster (L2, full slug set). Cache miss falls through to api-core's gRPC endpoint, which reads from Postgres.

Cache fill cadence: any update to a link's destination publishes an invalidation event on Redpanda. Edge POPs subscribe and drop their L1 entry for the affected slug. The next request to that slug hits L2 (still warm), populates L1. p95 invalidation latency is ~120ms across the three POPs.

This architecture is the redirect p95 < 15ms cornerstone post in operational detail. The architecture document at /docs/architecture/edge-redirect has the full diagram.

The decision tree#

A short checklist if you're picking between DNS-only and edge POP architectures:

Single-country user base + single origin? DNS-only is fine. Don't over-engineer.
Multi-country users + high cache hit ratio? Edge POPs. The latency win is dramatic at long-tail locations.
Multi-country users + personalised redirects on >50% of traffic? Mixed. POPs help with TLS termination but not with the redirect itself. Consider DNS routing + a small POP fleet for SSL termination only.
Strict SLA on failover speed? Edge POPs win — BGP withdrawal beats DNS TTL caching by orders of magnitude.
Sub-1M redirects/month? DNS-only is cheaper. Re-evaluate at 1M+.

There isn't a one-size-fits-all answer. URL shorteners specifically tend to fit the "multi-country + high cache hit ratio + strict failover SLA" bucket, which is why most production URL shorteners eventually move to an edge POP architecture. The transition cost (re-architecting cache fill, picking POP providers, BGP setup) is real but bounded.

Hitting p95 < 15ms for redirects from Frankfurt, Ashburn, and Singapore — cornerstone, with the operational detail
Cache strategy for URL redirects: what to evict and when — the L1/L2 cache architecture
Fire-and-forget click ingestion — what happens on the redirect path that isn't the cache lookup
Why ClickHouse for click analytics (and not Postgres) — the analytics side of the same architecture
Short links as Terraform: the engineering cornerstone — IaC for managing edge config