Edge-POPs vs. DNS-only-Routing: Der Latenz-Budget-Kompromiss

Das Latenz-Budget einer URL-Weiterleitung hat zwei Bereiche. Unter ~50 ms p50 befinden Sie sich im Edge-POP-Bereich - Anycast leitet den Nutzer zu einem nahen Cache, die Weiterleitung antwortet, bevor der TCP-Handshake aufwendig wird. Über ~50 ms befinden Sie sich im DNS-only-Bereich - DNS-basiertes Load-Balancing leitet den Client zur Namensauflösungszeit, die Weiterleitung ist ein kontinentübergreifender TCP-Hin- und Rückweg, und das Budget schließt diesen Hin- und Rückweg ein. Die Architekturen sehen oberflächlich ähnlich aus (beide liefern eine 302). Die Performance-Eigenschaften sind nicht dieselben. Dieser Beitrag ist der Vergleich.

Für das Latenz-Budget-Kernstück ist p95 < 15 ms für Weiterleitungen der ausführliche Artikel. Dieser Beitrag behandelt die architektonische Entscheidung dahinter.

Was "DNS-only-Routing" wirklich bedeutet

DNS-only-Routing beantwortet die Frage "Welchen Origin soll dieser Client treffen?" mit der DNS-Auflösung, nicht dem TCP-Pfad. Ein Nutzer in Sydney löst r.example.com auf, und der DNS-Anbieter (Route-53-Latenz-basiertes Routing, GeoDNS bei Cloudflare, NS1 usw.) gibt die IP des nächstgelegenen Origins zurück - sagen wir, die Sydney-Instanz Ihres Weiterleitungsdienstes.

Die Architektur:

Client (Sydney) ──DNS-Anfrage── Autoritative DNS
       │                            │
       │  gibt IP des Sydney-Pods zurück │
       ↓
   Sydney-Origin ──Weiterleitung 302──→ Client

Der DNS-Anbieter sieht die eigentliche HTTP-Anfrage nicht. Er sieht nur die Resolver-Anfrage - und dieser Resolver könnte ein Land entfernt sein, wodurch "nächstgelegen" zu einer Schätzung wird. Die HTTP-Anfrage selbst ist ein einziger Hin- und Rückweg zum gewählten Origin.

Hin- und Rückweg-Kosten. Der schnellste Pfad ist ein TCP-Handshake plus ein HTTP-Austausch zum nächsten Origin. Wenn der nächste Origin 40 ms entfernt ist (Sydney nach Sydney-lokal), löst die Weiterleitung in ~60-80 ms Wanduhr auf (Handshake plus Anfrage plus Antwort).

Fehlermodus. Wenn der gewählte Origin ausfällt, werden DNS-TTLs zum Engpass. Eine 60-Sekunden-TTL bedeutet, dass Clients bis zu eine Minute benötigen können, um den Ausfall zu erkennen und es gegen eine andere IP erneut zu versuchen. Die Health-Check-Frequenz des DNS-Anbieters legt das tatsächliche Wiederherstellungsfenster fest.

Was "Edge-POP-Routing" wirklich bedeutet

Edge-POP-Routing platziert eine Flotte von Cache-Servern in vielen Regionen, die alle auf derselben Anycast-IP antworten. Das erste Paket des Clients an diese IP wird per BGP an den topologisch nächstgelegenen POP geroutet - nicht nächstgelegen im geografischen Sinne, sondern im Netzwerksinne (wenigste Router-Hops, niedrigste gemessene Latenz).

Die Architektur:

Client (Sydney) ──Paket an Anycast-IP── BGP-nächster POP (Singapore)
                                              │
                                  Cache-Hit? antwortet 302
                                              │
                                  Cache-Miss → Origin (Frankfurt)
                                  Cache → antwortet 302

Der BGP-nächste POP bedient die Weiterleitung aus dem Cache. Cache-Hits überspringen den Origin vollständig. Cache-Misses sind selten (erster Miss eines heißen Links nach dem Deploy; der Deploy invalidiert eine Zeile pro Slug, nicht den gesamten Cache).

Hin- und Rückweg-Kosten. Ein Cache-Hit antwortet in 5-15 ms Wanduhr (TCP-Handshake zum lokalen POP, sofortige Antwort). Ein Cache-Miss fügt einen ~80-150 ms kontinentübergreifenden Hin- und Rückweg zum Origin hinzu - aber dieser Hin- und Rückweg passiert einmal, dann ist die Zeile für die nächste Anfrage am POP gecacht.

Fehlermodus. Wenn ein POP ausfällt, zieht BGP das Präfix zurück. Das nächste Paket des Clients geht automatisch zum nächstgelegenen POP. Die Wiederherstellung erfolgt in Sekundenbruchteilen, nicht in Minuten.

Die vier Kennzahlen, die entscheiden, welche Architektur passt

1. Ihre Origin-Anzahl. Wenn Sie einen einzigen Origin haben (Single-Region-Deployment), kann DNS-Routing nicht helfen - es gibt nichts, zwischen dem geroutet werden könnte. Anycast-POPs schaffen Mehrwert, indem sie den einzelnen Origin mit Caches vorlagern.

2. Ihre Cache-Hit-Rate. Edge-POPs sind nur schnell, wenn der Cache antwortet. URL-Shortener haben Hit-Raten von 95 % und mehr - die Slug-zu-Ziel-Map ist klein und leseintensiv. Wenn die Hit-Rate Ihres Workloads unter 50 % liegt, degradieren Edge-POPs zu "zusätzlichem Hop vor dem Origin", und DNS-Routing ist die sauberere Architektur.

3. Ihre geografische Verteilung. Wenn Ihre Nutzer zu 90 % und mehr in einem Land sind, performen beide Architekturen ähnlich - ein Origin in diesem Land ist bereits für alle unter 30 ms erreichbar. Wenn Ihre Nutzer über Kontinente verteilt sind, beginnt die Edge-POP-Architektur zu gewinnen. Ein Nutzer in Sydney, der einen nur in Frankfurt gehosteten Origin via DNS-Routing trifft, zahlt den kontinentübergreifenden RTT (~180-220 ms TCP-Handshake) bei jeder Weiterleitung. Mit einem Edge-POP in Singapore zahlt derselbe Nutzer ~25 ms.

4. Ihre Fehlertoleranz gegenüber langsamer Propagierung. DNS-basierte Wiederherstellung wird durch die TTL-Caching-Dauer des langsamsten Resolvers begrenzt. Manche Resolver halten sich nicht an niedrige TTLs; sie begrenzen die Mindest-TTL auf 60 oder 300 Sekunden. Wenn Ihr URL-Shortener gelegentlich einen Origin offline schalten muss (Deploy, Wartung, Region-Ausfall), hinterlässt DNS-Routing eine lange Tail-Gruppe von Clients auf dem toten Origin. Anycast zieht sich in Sekundenbruchteilen zurück.

Stellen Sie die vier Kennzahlen einem typischen URL-Shortener-Workload gegenüber:

• Origin-Anzahl: typischerweise 2-3 (multi-region für Redundanz)
• Cache-Hit-Rate: 95-99 % (Slug-Map ist klein)
• Geografische Verteilung: typischerweise multi-kontinental (jede verbraucherorientierte Marke)
• Fehlertoleranz: null (der Link steht auf Printmaterialien; Ausfallzeiten kosten Vertrauen)

Alle vier sprechen für Edge-POPs. Die DNS-only-Architektur ist eher geeignet für interne B2B-SaaS-Tools, bei denen die Weiterleitungsfläche regional ist und die Slug-Map häufig wechselt (mehr Cache-Invalidierungen als Reads).

Wie die Latenzwerte tatsächlich aussehen

Wir haben beide Architekturen von vier Standorten aus gegen denselben Workload gemessen (einzelner Kurzlink, kalter Cache dann warmer Cache). Die Werte unten sind p50 / p95 aus 1000 sequenziellen Anfragen pro Standort.

DNS-only-Routing (einzelner Origin in Frankfurt, GeoDNS-Routing):

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

Edge-POP-Routing (Anycast über FRA, ASH, SGP), Cache-HIT:

Client-Standort	Leitet zu POP	p50	p95
Frankfurt	FRA	3 ms	7 ms
London	FRA	11 ms	18 ms
New York	ASH	5 ms	9 ms
Singapore	SGP	4 ms	8 ms

Der Unterschied zeigt sich bei den entfernten Standorten. Frankfurt sieht in beiden Architekturen ähnlich aus, weil es im DNS-only-Fall der Origin ist. Singapore ist der dramatische Fall: 195 ms p50 zu 4 ms p50, weil die Edge-POP-Architektur direkt aus Singapore antwortet. Die DNS-only-Architektur zahlt den kontinentübergreifenden Hin- und Rückweg bei jeder Weiterleitung, egal wie gecacht.

Kosten-Kompromiss

Edge-POPs kosten bei geringem Volumen mehr pro Weiterleitung. Die Fixkosten des Betriebs eines POP - selbst eines kleinen auf einer Hetzner-Falkenstein-Box - sind real. Bei unter 100.000 Weiterleitungen pro Monat ist DNS-only-Routing gegen einen einzelnen Origin günstiger.

Der Kreuzungspunkt liegt bei etwa 1 Million Weiterleitungen pro Monat. Darüber gewinnt die Edge-POP-Architektur bei den Kosten pro Weiterleitung, weil Cache-Hit-Antworten weder Origin-Rechenleistung noch Origin-Bandbreite verbrauchen. Der Origin skaliert für Cache-Fills (~1 % der Anfragen) statt für das gesamte Anfragevolumen.

Die meisten URL-Shortener liegen von Tag eins an über dem Kreuzungspunkt, weil die Workload-Verteilung schwanzlastig ist - einige wenige heiße Links tragen den Großteil des Klickvolumens, und diese Links haben effektiv unendliche Cache-Hit-Raten.

Was Edge-POPs nicht lösen

Edge-POPs sind kein universelles Upgrade. Drei Workloads, bei denen sie langsamer statt schneller machen:

1. Schreibvorgänge. Das Erstellen eines neuen Links, das Aktualisieren eines Ziels - diese müssen beim autoritativen Origin landen und sich dann auf die Cache-Invalidierungsschicht propagieren. Leselatenz ist gut; Schreiblatenz ist ungefähr gleich wie beim Origin-only-Pfad.

2. Personalisierte Weiterleitungen. Smart Links, die anhand der Nutzeridentität routen (nicht nur nach Slug), können am POP nicht gecacht werden - sie müssen jedes Mal den Origin treffen, um das Nutzerprofil zu lesen. Der POP wird zu einem dünnen TLS-Terminierungsproxy und fügt 5-10 ms hinzu, was ansonsten ein direkter Origin-Zugriff wäre. Für die meisten URL-Shortener ist das in Ordnung, weil personalisierte Weiterleitungen eine kleine Minderheit des Traffics ausmachen. Bei Deep-Link-Produkten (Branch, Adjust) liegt die Personalisierungsrate näher an 50 %, was die Architektur-Mathematik verändert.

3. Geo-eingeschränkte Ziele. Wenn sich das Weiterleitungs-Ziel nach Nutzer-Geografie ändert (unterschiedliche Landingpage pro Land), muss der Cache-Schlüssel das Land enthalten. Das fragmentiert den Cache - statt einer Zeile pro Slug gibt es N Zeilen pro Slug für N unterstützte Länder. Die Cache-Hit-Rate sinkt; die Cache-Speicherkosten steigen. Die POPs helfen immer noch, nur weniger.

Für URL-Shortener ist der dritte Fall der zu beobachtende. Die meisten Kurzlinks lösen zu einer URL auf, unabhängig von der Nutzer-Geografie, sodass ein einzelner Cache-Schlüssel funktioniert. Sobald Sie jedoch Länder-Varianten hinzufügen, verschiebt sich die Kostengleichung.

So macht Elido das

Drei POPs (Hetzner Falkenstein, Hetzner Ashburn, OVH Singapore), Anycast über ein /24, das wir besitzen. Caddy am Edge für TLS und On-demand-Zertifikate; fasthttp hinter Caddy für die eigentliche Weiterleitung. Zweistufiger Cache: In-Process-LRU (L1, ~10.000 heißeste Slugs im Arbeitsspeicher) - Redis Cluster (L2, vollständige Slug-Menge). Cache-Miss greift auf den gRPC-Endpunkt von api-core zurück, der aus Postgres liest.

Cache-Fill-Frequenz: Jede Aktualisierung des Ziels eines Links veröffentlicht ein Invalidierungsereignis auf Redpanda. Edge-POPs abonnieren und verwerfen ihren L1-Eintrag für den betroffenen Slug. Die nächste Anfrage an diesen Slug trifft L2 (noch warm) und befüllt L1. p95-Invalidierungslatenz beträgt ~120 ms über die drei POPs.

Diese Architektur ist das Weiterleitungs-p95-<-15-ms-Kernstück in operativer Detailtiefe. Das Architekturdokument unter /docs/architecture/edge-redirect enthält das vollständige Diagramm.

Der Entscheidungsbaum

Eine kurze Checkliste, wenn Sie zwischen DNS-only- und Edge-POP-Architekturen wählen:

• Nutzerbasis in einem Land plus einzelner Origin? DNS-only ist ausreichend. Nicht über-engineeren.
• Multi-Länder-Nutzer plus hohe Cache-Hit-Rate? Edge-POPs. Der Latenzgewinn ist an entfernten Standorten dramatisch.
• Multi-Länder-Nutzer plus personalisierte Weiterleitungen auf mehr als 50 % des Traffics? Gemischt. POPs helfen bei der TLS-Terminierung, aber nicht bei der Weiterleitung selbst. Erwägen Sie DNS-Routing plus eine kleine POP-Flotte nur für SSL-Terminierung.
• Striktes SLA für Failover-Geschwindigkeit? Edge-POPs gewinnen - BGP-Rückzug schlägt DNS-TTL-Caching um Größenordnungen.
• Unter 1 Million Weiterleitungen pro Monat? DNS-only ist günstiger. Bei 1 Million und mehr neu bewerten.

Es gibt keine Einheitslösung. URL-Shortener passen speziell in den Bereich "multi-kontinental plus hohe Cache-Hit-Rate plus striktes Failover-SLA", weshalb die meisten Produktions-URL-Shortener letztendlich zu einer Edge-POP-Architektur übergehen. Die Übergangskosten (Cache-Fill neu architekturieren, POP-Anbieter auswählen, BGP-Setup) sind real, aber begrenzt.

Weitere Blog-Beiträge

• p95 < 15 ms für Weiterleitungen aus Frankfurt, Ashburn und Singapore - Kernstück mit den operativen Details
• Cache-Strategie für URL-Weiterleitungen: was verdrängen und wann - die L1/L2-Cache-Architektur
• Fire-and-forget Klick-Ingestion - was auf dem Weiterleitungspfad passiert, das nicht die Cache-Abfrage ist
• Warum ClickHouse für Klick-Analysen (und nicht Postgres) - die Analytics-Seite derselben Architektur
• Kurzlinks als Terraform: das Engineering-Kernstück - IaC zur Verwaltung von Edge-Konfigurationen