La matematica della latenza: cosa impone la fisica
La luce nel vuoto viaggia a 299.792 km/s. La luce nei cavi a fibra ottica viaggia a circa 2/3 di quella — circa 200.000 km/s, o circa 5 ms per 1.000 km in una sola direzione. Il tempo di andata e ritorno (RTT) è il doppio: ~10 ms per 1.000 km di cavo. I percorsi in fibra del mondo reale sono solitamente 1,3-2x la distanza geodetica, quindi consideri la latenza extra per le realtà del routing.
La luce rallenta nel vetro a causa dell'indice di rifrazione. L'indice di rifrazione della fibra single-mode è approssimativamente 1,467, quindi la velocità della luce nella fibra è c/1,467 ≈ 204.300 km/s. Questo dà una latenza one-way di circa 4,9 ms per 1.000 km di fibra e un round-trip di 9,8 ms. Questo è un pavimento fisico duro — nessuna quantità di ingegneria del fornitore può battere la velocità della luce. Una regola pratica più utile per la pianificazione di produzione: budget di 1 ms per 100 km in una sola direzione, più 1-2 ms di overhead di switching e routing per hop di rete. I cavi sottomarini di lungo raggio sono ben progettati e si avvicinano al minimo teorico (Londra-New York è circa 70 ms RTT, vicino al limite geodetico di 5.500 km). L'ultimo miglio e i percorsi intra-città sono spesso 5-15 ms a causa dei salti di router e della geometria del peering ISP piuttosto che della distanza.
Stime RTT reali tra le principali città
Tempi di andata e ritorno approssimativi (RTT completi) tra i principali hub di hosting nel 2026: Londra-Amsterdam ~10 ms, Londra-Francoforte ~15 ms, Londra-New York ~70 ms, New York-San Francisco ~70 ms, Francoforte-Singapore ~160 ms, Londra-Sydney ~250 ms, Tokyo-San Francisco ~100 ms. Questi sono valori tipici fiber-best-case misurati TCP-to-TCP tra peer datacenter.
Questi numeri provengono dai dati di peering pubblici pubblicati dai principali IXP (LINX, AMS-IX, DE-CIX, KINX) e da atlas di latenza su larga scala (RIPE Atlas, WonderNetwork, Cloudping). Il Suo RTT reale varierà del 10-30% a seconda del momento della giornata, delle relazioni di peering tra il Suo fornitore e l'ISP del Suo utente, e del percorso specifico del cavo sottomarino utilizzato. I numeri sopra sono tipici, non garantiti, e presumono che entrambi gli endpoint siano in datacenter con transito multi-Tbps. Le connessioni residenziali dell'ultimo miglio aggiungono altri 5-30 ms sopra il pavimento datacenter-a-datacenter.
| Da | A | Distanza (geodetica) | RTT tipico |
|---|---|---|---|
| Londra | Amsterdam | 360 km | ~10 ms |
| Londra | Francoforte | 640 km | ~15 ms |
| Londra | Parigi | 340 km | ~10 ms |
| Francoforte | Varsavia | 900 km | ~20 ms |
| Londra | New York | 5.570 km | ~70 ms |
| New York | Miami | 1.760 km | ~30 ms |
| New York | San Francisco | 4.140 km | ~70 ms |
| San Francisco | Tokyo | 8.280 km | ~100 ms |
| Francoforte | Singapore | 10.290 km | ~160 ms |
| Londra | Sydney | 16.990 km | ~250 ms |
| Francoforte | Mumbai | 6.580 km | ~110 ms |
| San Paolo | Miami | 6.580 km | ~120 ms |
Residenza dei dati: GDPR, CLOUD Act e gli altri
I dati personali UE/SEE rientrano nel GDPR (Regolamento (UE) 2016/679), che limita i trasferimenti al di fuori del SEE senza specifiche garanzie. Il CLOUD Act statunitense (2018) consente alle autorità statunitensi di obbligare i fornitori con sede negli USA a divulgare dati indipendentemente da dove siano fisicamente archiviati. Russia e Cina hanno i propri regimi di localizzazione dei dati. Scelga una regione datacenter che si allinei sia con le giurisdizioni dei Suoi utenti sia con i Suoi obblighi contrattuali.
Il GDPR (in vigore da maggio 2018) tratta qualsiasi dato personale di residenti UE o SEE — nome, email, indirizzo IP, dati comportamentali — come regolamentato indipendentemente da dove sia con sede il titolare. I trasferimenti transfrontalieri richiedono una decisione di adeguatezza, Clausole Contrattuali Standard, o Norme Vincolanti d'Impresa. Le deroghe dell'Articolo 49 sono ristrette. La sentenza Schrems II (Corte di Giustizia dell'Unione Europea, luglio 2020) ha annullato Privacy Shield e ha notevolmente irrigidito le garanzie di trasferimento. Il CLOUD Act statunitense (Clarifying Lawful Overseas Use of Data Act, 2018) consente alle autorità federali statunitensi di obbligare qualsiasi fornitore con sede negli USA a produrre dati archiviati, anche se i dati si trovano su un server a Francoforte. Questo crea una tensione per i clienti europei che utilizzano fornitori di hosting con sede negli USA, indipendentemente da quale datacenter ospiti fisicamente i loro dati. La Legge Federale Russa N. 242-FZ richiede che i dati personali dei cittadini russi siano elaborati inizialmente su server fisicamente all'interno della Russia. La PIPL cinese (Personal Information Protection Law, in vigore da novembre 2021) richiede la localizzazione per gli operatori di infrastrutture informatiche critiche e per i processori di dati ad alto volume. Nessuno di questi regimi si preoccupa di dove girano i Suoi server applicativi; tutti si preoccupano di dove vengono archiviati ed elaborati i dati personali.
Quando ha senso multi-regione
Multi-regione è giustificato quando ha utenti distribuiti geograficamente con requisiti di latenza sub-100 ms, quando ha obblighi normativi di residenza dei dati attraverso giurisdizioni, o quando il rischio di downtime mono-regione è inaccettabile. Raramente è giustificato per progetti hobbystici, SaaS a basso traffico con utenti in una regione, o carichi di lavoro dove la complessità ingegneristica supera i guadagni di latenza.
Multi-regione aggiunge tre costi concreti. Primo, complessità ingegneristica: replica dei dati (consistente eventualmente o sincrona globalmente), logica di routing (geo-DNS, anycast, failover regionale) e osservabilità tra regioni moltiplicano tutti la superficie operativa. Secondo, costo dell'infrastruttura: almeno il doppio del compute e dello storage, più le tariffe di transito inter-regione che i fornitori cloud addebitano per GB. Terzo, compromessi di consistenza: le scritture globali sincrone sono fisicamente limitate dalla stessa matematica di latenza della sezione precedente, quindi la maggior parte dei design multi-regione accetta una qualche forma di consistenza eventuale. Le giustificazioni che valgono quel costo: utenti reali distribuiti tra continenti dove una latenza di 200+ ms affossa la conversione, requisiti di RTO sub-secondo per disaster recovery, obblighi normativi di mantenere i dati UE nell'UE e i dati USA negli USA simultaneamente, o requisiti di alta disponibilità active-active dove qualsiasi interruzione di un singolo datacenter deve essere invisibile. La maggior parte dei carichi di lavoro di produzione non ne ha bisogno; molti design ingegnerizzano eccessivamente verso di esso.
Albero decisionale: come scegliere una regione
Passo 1: identifichi dove vive l'80% dei Suoi utenti (analytics, log CDN, mercato target previsto). Passo 2: scelga la regione di hosting più vicina. Passo 3: controlli che la giurisdizione legale corrisponda ai Suoi obblighi di residenza dei dati. Passo 4: aggiunga una seconda regione solo se il passo 1 rivela un secondo cluster di utenti a più di 100 ms RTT dal primo, o se i requisiti HA/DR lo richiedono.
Esegua l'albero onestamente. Per un tipico SaaS focalizzato sull'Europa con utenti principalmente in Germania, Francia, Regno Unito e Paesi Bassi, un singolo datacenter dell'Europa occidentale (Francoforte, Amsterdam o Londra) mantiene ogni utente sotto 30 ms RTT e soddisfa il GDPR in modo pulito. Per un prodotto B2B focalizzato sugli USA con utenti da Boston a Los Angeles, un singolo datacenter US East (Ashburn, NYC) mantiene gli utenti della East Coast sotto 20 ms e quelli della West Coast sotto 80 ms — male per il gaming, bene per la maggior parte dei SaaS. Per prodotti veramente globali (app web con utenti su ogni continente), una regione primaria più una CDN con presenza edge globale di solito batte l'esecuzione active-active in tre datacenter. Per prodotti con requisiti rigorosi di residenza dei dati attraverso giurisdizioni (un piano dati solo UE e solo USA), multi-regione diventa obbligatorio indipendentemente dalla latenza.
Scorciatoie di compliance: certificazioni che significano davvero qualcosa
Cerchi ISO/IEC 27001 (gestione della sicurezza delle informazioni), SOC 2 Type II (controlli operativi auditati nel tempo, non in un singolo momento), e PCI DSS Level 1 (dati di pagamento) se si applicano. Per i clienti UE, cerchi accordi espliciti di trattamento dati GDPR (DPA) e una chiara lista di sub-processori. Il marketing generico 'sicurezza enterprise' senza certificazioni nominate è essenzialmente privo di significato.
Tre certificazioni hanno peso reale. ISO/IEC 27001:2022 è lo standard internazionale per i sistemi di gestione della sicurezza delle informazioni e richiede un audit indipendente e audit di sorveglianza continui. SOC 2 Type II audita i controlli di un'organizzazione su una finestra di osservazione di 6-12 mesi, distinguendolo da Type I (point-in-time). PCI DSS si applica se gestisce carte di pagamento; Level 1 è per organizzazioni che elaborano oltre 6 milioni di transazioni/anno. Per i clienti europei, il DPA GDPR (data-processing addendum) è contrattualmente vincolante ed elenca esattamente cosa il fornitore può e non può fare con i Suoi dati. Oltre a quelli, cerchi rapporti di trasparenza (con quale frequenza il fornitore riceve richieste delle forze dell'ordine?), una lista pubblicata di sub-processori (terze parti che toccano i Suoi dati) e chiare garanzie di cancellazione dei dati alla risoluzione del contratto. Frasi generiche come 'sicurezza bancaria' o 'crittografia di livello militare' non Le dicono nulla — l'algoritmo AES-256 sottostante è lo stesso ovunque.