Il budget di latenza per un reindirizzamento URL ha due regimi. Al di sotto di circa 50ms p50, sei in territorio edge POP - anycast instrada l'utente verso una cache vicina, il reindirizzamento risponde prima che l'handshake TCP sembri costoso. Al di sopra di circa 50ms, sei in territorio DNS-only - il bilanciamento del carico basato su DNS instrada il client al momento della risoluzione del nome, il reindirizzamento e' un singolo round trip TCP intercontinentale, e il budget include quel round trip. Le architetture sembrano superficialmente simili (entrambe servono un 302). Le performance envelope non sono le stesse. Questo post e' il confronto.
Per la pietra angolare sul budget di latenza, raggiungere p95 < 15ms per i reindirizzamenti e' la lettura lunga. Questo post e' la decisione architetturale dietro di essa.
Cosa significa davvero "routing DNS-only"
Il routing DNS-only risponde alla domanda "quale origine dovrebbe colpire questo client?" con la risoluzione DNS, non il percorso TCP. Un utente a Sydney risolve r.example.com e il provider DNS (routing basato sulla latenza di Route 53, GeoDNS su Cloudflare, NS1, ecc.) restituisce l'IP dell'origine piu' vicina - diciamo, l'istanza Sydney del tuo servizio di reindirizzamento.
L'architettura:
Client (Sydney) ──query DNS── DNS autoritativo
│ │
│ restituisce IP del pod Sydney │
↓
Origine Sydney ──redirect 302──→ Client
Il provider DNS non vede la richiesta HTTP effettiva. Vede solo la query del resolver - e quel resolver potrebbe essere a un paese di distanza, nel qual caso "piu' vicino" diventa un'ipotesi. La richiesta HTTP stessa e' un round trip verso l'origine scelta.
Costo round-trip. Il percorso piu' veloce e' un handshake TCP + uno scambio HTTP verso l'origine piu' vicina. Se l'origine piu' vicina e' a 40ms di distanza (Sydney → locale a Sydney), il reindirizzamento si risolve in circa 60-80ms wall-clock (handshake + richiesta + risposta).
Modalita' di guasto. Quando l'origine scelta e' fuori servizio, i TTL DNS diventano il collo di bottiglia. Un TTL di 60 secondi significa che i client possono impiegare fino a un minuto per rilevare il guasto e riprovare contro un IP diverso. La cadenza di health-check del provider DNS imposta la finestra di recovery effettiva.
Cosa significa davvero "routing edge POP"
Il routing edge POP mette una flotta di server cache in molte regioni, tutti che rispondono sullo stesso IP anycast. Il primo pacchetto del client verso quell'IP viene instradato da BGP al POP topologicamente piu' vicino - non il piu' vicino geograficamente, ma il piu' vicino nel senso della rete (meno hop del router, latenza misurata piu' bassa).
L'architettura:
Client (Sydney) ──pacchetto verso IP anycast── POP piu' vicino BGP (Singapore)
│
Cache hit? rispondi 302
│
Cache miss → origine (Francoforte)
Cache → rispondi 302
Il POP piu' vicino BGP serve il reindirizzamento dalla cache. I cache hit saltano completamente l'origine. I cache miss sono infrequenti (il primo miss di un link popolare dopo il deploy; il deploy invalida una riga per slug, non tutta la cache).
Costo round-trip. Un cache hit risponde in 5-15ms wall-clock (handshake TCP al POP locale, risposta immediata). Un cache miss aggiunge un round trip intercontinentale di circa 80-150ms verso l'origine - ma quel round trip avviene una volta, poi la riga viene messa in cache al POP per la richiesta successiva.
Modalita' di guasto. Quando un POP si guasta, BGP ritira il prefisso. Il pacchetto successivo del client va automaticamente al POP piu' vicino successivo. Il recovery e' sotto il secondo, non sotto il minuto.
I quattro numeri che decidono quale architettura si adatta
-
Il tuo numero di origini. Se hai una sola origine (deployment single-region), il routing DNS non puo' aiutare - non c'e' nulla tra cui instradare. I POP anycast aggiungono valore fronteggiando la singola origine con le cache.
-
Il tuo tasso di cache hit. Gli edge POP sono veloci solo quando risponde la cache. Gli URL shortener hanno tassi di hit nell'ordine del 95%+ - la mappa slug→destinazione e' piccola e dominata dalle letture. Se il tasso di hit del tuo workload e' inferiore al 50%, gli edge POP degenerano in "hop extra prima dell'origine", e il routing DNS e' l'architettura piu' pulita.
-
La tua distribuzione geografica. Se il 90%+ dei tuoi utenti si trova in un paese, entrambe le architetture hanno prestazioni simili - un'origine in quel paese e' gia' a meno di 30ms da tutti. Se i tuoi utenti sono distribuiti tra i continenti, l'architettura edge POP inizia a vincere. Un utente a Sydney che colpisce un'origine solo a Francoforte tramite routing DNS paga il RTT intercontinentale (circa 180-220ms handshake TCP) ad ogni reindirizzamento. Con un edge POP a Singapore, lo stesso utente paga circa 25ms.
-
La tua tolleranza ai guasti per la propagazione lenta. Il recovery basato su DNS e' vincolato dal caching TTL del resolver piu' lento. Alcuni resolver non rispettano i TTL bassi; fissano il TTL minimo a 60 o 300 secondi. Se il tuo URL shortener ha occasionalmente bisogno di mettere offline un'origine (deploy, manutenzione, region-out), il routing DNS lascia una lunga coda di client sull'origine morta. Anycast si ritira in meno di un secondo.
Traccia i quattro numeri rispetto a un workload tipico di URL shortener:
- Numero di origini: tipicamente 2-3 (multi-region per ridondanza)
- Tasso di cache hit: 95-99% (la mappa slug e' piccola)
- Distribuzione geografica: tipicamente multi-continente (qualsiasi brand rivolto ai consumatori)
- Tolleranza ai guasti: zero (il link e' nei materiali stampati; il downtime costa fiducia)
Tutti e quattro spingono verso gli edge POP. L'architettura DNS-only e' piu' appropriata per strumenti interni SaaS B2B dove la superficie di reindirizzamento e' regionale e la mappa slug cambia frequentemente (piu' invalidazioni della cache che letture).
Come appaiono davvero i numeri di latenza
Abbiamo fatto il benchmark di entrambe le architetture da quattro posizioni rispetto allo stesso workload (singolo short link, prima cold-cache poi warm-cache). I numeri di seguito sono p50 / p95 da 1000 richieste sequenziali per posizione.
Routing DNS-only (singola origine a Francoforte, routing GeoDNS):
| Posizione origine | Client → Francoforte | p50 | p95 |
|---|---|---|---|
| Francoforte | <1ms | 4ms | 9ms |
| Londra | 14ms | 22ms | 35ms |
| New York | 90ms | 110ms | 145ms |
| Singapore | 165ms | 195ms | 240ms |
Routing edge POP (anycast su FRA, ASH, SGP), cache HIT:
| Posizione client | Instrada verso POP | p50 | p95 |
|---|---|---|---|
| Francoforte | FRA | 3ms | 7ms |
| Londra | FRA | 11ms | 18ms |
| New York | ASH | 5ms | 9ms |
| Singapore | SGP | 4ms | 8ms |
Il divario e' nelle posizioni a coda lunga. Francoforte appare simile in entrambi perche' e' l'origine nel caso DNS-only. Singapore e' quella drammatica: 195ms p50 contro 4ms p50, perche' l'architettura edge POP risponde direttamente da Singapore. L'architettura DNS-only paga il round trip intercontinentale ad ogni reindirizzamento, indipendentemente dalla cache.
Tradeoff di costo
Gli edge POP costano di piu' per reindirizzamento a basso volume. Il costo fisso di gestione di un POP - anche uno piccolo su una macchina Hetzner Falkenstein - e' reale. A meno di 100k reindirizzamenti/mese, il routing DNS-only contro una singola origine e' piu' economico.
Il punto di incrocio e' intorno a 1M di reindirizzamenti/mese. Al di sopra di questo, l'architettura edge POP vince sul costo-per-reindirizzamento perche' le risposte con cache hit non toccano il compute o la larghezza di banda dell'origine. L'origine scala per i riempimenti della cache (circa 1% delle richieste) piuttosto che per il volume totale delle richieste.
La maggior parte degli URL shortener e' al di sopra del punto di incrocio dal primo giorno perche' la distribuzione del workload ha una coda pesante - pochi link molto popolari portano la maggior parte del volume dei clic, e quei link hanno tassi di cache hit praticamente infiniti.
Cosa gli edge POP non risolvono
Gli edge POP non sono un aggiornamento universale. Tre workload che rendono piu' lenti, non piu' veloci:
-
Le scritture. Creare un nuovo link, aggiornare una destinazione - questi devono atterrare sull'origine autoritativa, poi propagarsi al livello di invalidazione della cache. La latenza di lettura e' ottima; la latenza di scrittura e' approssimativamente la stessa del percorso solo-origine.
-
Reindirizzamenti personalizzati. I link intelligenti che instradano sull'identita' dell'utente (non solo sullo slug) non possono essere memorizzati nella cache al POP - devono colpire l'origine ogni volta per leggere il profilo dell'utente. Il POP diventa un proxy sottile di terminazione TLS, aggiungendo 5-10ms a quello che altrimenti sarebbe un colpo diretto all'origine. Per la maggior parte degli URL shortener questo va bene perche' i reindirizzamenti personalizzati sono una piccola minoranza del traffico. Per i prodotti deep link (Branch, Adjust), il tasso di personalizzazione e' piu' vicino al 50%, il che cambia i calcoli dell'architettura.
-
Destinazioni geo-ristrette. Se la destinazione del reindirizzamento cambia in base alla geografia dell'utente (pagina di destinazione diversa per paese), la chiave della cache deve includere il paese. Questo frammenta la cache - invece di una riga per slug, hai N righe per slug per N paesi supportati. Il tasso di cache hit scende; il costo di memoria della cache sale. I POP aiutano comunque, semplicemente meno.
Per gli URL shortener, il terzo caso e' quello da tenere d'occhio. La maggior parte dei short link si risolve in un unico URL indipendentemente dalla geo dell'utente, quindi una singola chiave di cache funziona. Ma una volta aggiustate le varianti per paese, l'equazione dei costi cambia.
Come lo fa Elido
Tre POP (Hetzner Falkenstein, Hetzner Ashburn, OVH Singapore), anycast su un /24 di nostra proprieta'. Caddy sull'edge per TLS + certificati on-demand; fasthttp dietro Caddy per il reindirizzamento stesso. Cache a due livelli: LRU in-process (L1, circa 10k slug piu' caldi in memoria) → Redis Cluster (L2, set di slug completo). I cache miss cadono attraverso l'endpoint gRPC di api-core, che legge da Postgres.
Cadenza di riempimento della cache: qualsiasi aggiornamento alla destinazione di un link pubblica un evento di invalidazione su Redpanda. Gli edge POP si iscrivono e eliminano la loro voce L1 per lo slug interessato. La richiesta successiva a quello slug colpisce L2 (ancora caldo), popola L1. La latenza di invalidazione p95 e' circa 120ms sui tre POP.
Questa architettura e' il post redirect p95 < 15ms cornerstone con dettagli operativi. Il documento di architettura su /docs/architecture/edge-redirect ha il diagramma completo.
L'albero decisionale
Una breve checklist se stai scegliendo tra architetture DNS-only e edge POP:
- Base utenti in un singolo paese + singola origine? DNS-only va bene. Non over-engineer.
- Utenti multi-paese + alto tasso di cache hit? Edge POP. Il vantaggio di latenza e' drammatico nelle posizioni a coda lunga.
- Utenti multi-paese + reindirizzamenti personalizzati su oltre il 50% del traffico? Misto. I POP aiutano con la terminazione TLS ma non con il reindirizzamento stesso. Considera il routing DNS + una piccola flotta di POP solo per la terminazione SSL.
- SLA rigoroso sulla velocita' di failover? Gli edge POP vincono - il ritiro BGP batte il caching TTL DNS di ordini di grandezza.
- Meno di 1M reindirizzamenti/mese? DNS-only e' piu' economico. Rivaluta a 1M+.
Non esiste una risposta valida per tutti. Gli URL shortener in particolare tendono a rientrare nel bucket "multi-paese + alto tasso di cache hit + SLA failover rigoroso", motivo per cui la maggior parte degli URL shortener in produzione alla fine passa a un'architettura edge POP. Il costo di transizione (ristrutturazione del riempimento della cache, scelta dei provider POP, configurazione BGP) e' reale ma limitato.
Correlati sul blog
- Raggiungere p95 < 15ms per i reindirizzamenti da Francoforte, Ashburn e Singapore - pietra angolare, con i dettagli operativi
- Strategia di cache per i reindirizzamenti URL: cosa evitare e quando - l'architettura cache L1/L2
- Ingestione clic fire-and-forget - cosa succede nel percorso di reindirizzamento che non e' la ricerca in cache
- Perche' ClickHouse per le analytics dei clic (e non Postgres) - il lato analytics della stessa architettura
- Short link come Terraform: la pietra angolare di ingegneria - IaC per la gestione della configurazione edge
Prova Elido
Incolla un URL, ottieni un link breve
Senza registrazione. Il link vive 30 giorni. Iscriviti per conservarlo.
Gratis, nessuna registrazione richiesta · 2 al giorno