A matemática da latência: o que a física impõe
A luz no vácuo viaja a 299.792 km/s. A luz em cabo de fibra óptica viaja a aproximadamente 2/3 disso — cerca de 200.000 km/s, ou aproximadamente 5 ms por 1.000 km de ida. O tempo de ida e volta (RTT) é o dobro disso: ~10 ms por 1.000 km de cabo. Caminhos de fibra reais geralmente são 1,3-2x a distância em arco geodésico, então considere latência extra para realidades de roteamento.
A luz desacelera no vidro por causa do índice de refração. O índice de refração da fibra monomodo é aproximadamente 1,467, então a velocidade da luz na fibra é c/1,467 ≈ 204.300 km/s. Isso dá uma latência de ida de cerca de 4,9 ms por 1.000 km de fibra e um RTT de 9,8 ms. Esse é um piso físico inflexível — nenhuma engenharia de provedor vence a velocidade da luz. Uma regra prática mais útil para planejamento de produção: orce 1 ms por 100 km de ida, mais 1-2 ms de overhead de comutação e roteamento por hop de rede. Cabos submarinos de longa distância são bem projetados e se aproximam do mínimo teórico (Londres-Nova York é cerca de 70 ms RTT, perto do limite de arco geodésico de 5.500 km). Caminhos last-mile e intracidade são frequentemente 5-15 ms por causa de hops de roteador e geometria de peering de ISP, em vez da distância.
Estimativas reais de RTT entre grandes cidades
Tempos aproximados de ida e volta (RTT completo) entre grandes hubs de hospedagem em 2026: Londres-Amsterdã ~10 ms, Londres-Frankfurt ~15 ms, Londres-Nova York ~70 ms, Nova York-São Francisco ~70 ms, Frankfurt-Singapura ~160 ms, Londres-Sydney ~250 ms, Tóquio-São Francisco ~100 ms. Esses são valores típicos no melhor caso de fibra medidos TCP-a-TCP entre pares de datacenter.
Esses números vêm dos dados públicos de peering publicados por grandes IXPs (LINX, AMS-IX, DE-CIX, KINX) e atlas de latência em larga escala (RIPE Atlas, WonderNetwork, Cloudping). Seu RTT real variará 10-30% dependendo do horário, das relações de peering entre seu provedor e o ISP do seu usuário e do caminho de cabo submarino específico usado. Os números acima são típicos, não garantidos, e assumem que ambos os endpoints estão em datacenters com trânsito multi-Tbps. Conexões residenciais last-mile adicionam mais 5-30 ms ao piso datacenter-a-datacenter.
| De | Para | Distância (arco geodésico) | RTT típico |
|---|---|---|---|
| Londres | Amsterdã | 360 km | ~10 ms |
| Londres | Frankfurt | 640 km | ~15 ms |
| Londres | Paris | 340 km | ~10 ms |
| Frankfurt | Varsóvia | 900 km | ~20 ms |
| Londres | Nova York | 5.570 km | ~70 ms |
| Nova York | Miami | 1.760 km | ~30 ms |
| Nova York | São Francisco | 4.140 km | ~70 ms |
| São Francisco | Tóquio | 8.280 km | ~100 ms |
| Frankfurt | Singapura | 10.290 km | ~160 ms |
| Londres | Sydney | 16.990 km | ~250 ms |
| Frankfurt | Mumbai | 6.580 km | ~110 ms |
| São Paulo | Miami | 6.580 km | ~120 ms |
Residência de dados: LGPD/GDPR, CLOUD Act e o resto
Dados pessoais da UE/EEE estão sob o GDPR (Regulamento (UE) 2016/679), que restringe transferências para fora do EEE sem salvaguardas específicas. O CLOUD Act dos EUA (2018) permite que autoridades dos EUA obriguem provedores sediados nos EUA a divulgar dados, independentemente de onde estejam fisicamente armazenados. Rússia e China têm seus próprios regimes de localização de dados. Escolha uma região de datacenter que se alinhe tanto às jurisdições de seus usuários quanto às suas obrigações contratuais.
O GDPR (em vigor desde maio de 2018) trata qualquer dado pessoal de residentes da UE ou do EEE — nome, e-mail, endereço IP, dados comportamentais — como regulado, independentemente de onde o controlador esteja sediado. Transferências transfronteiriças exigem decisão de adequação, Cláusulas Contratuais Padrão ou Regras Corporativas Vinculativas. Derrogações do artigo 49 são restritas. A decisão Schrems II (Tribunal de Justiça da União Europeia, julho de 2020) derrubou o Privacy Shield e endureceu consideravelmente as salvaguardas de transferência. O CLOUD Act dos EUA (Clarifying Lawful Overseas Use of Data Act, 2018) permite que autoridades federais dos EUA obriguem qualquer provedor sediado nos EUA a produzir dados armazenados, mesmo que estejam em um servidor em Frankfurt. Isso cria tensão para clientes europeus que usam provedores de hospedagem sediados nos EUA, independentemente de em qual datacenter os dados fisicamente vivem. A Lei Federal Russa nº 242-FZ exige que os dados pessoais de cidadãos russos sejam processados inicialmente em servidores fisicamente dentro da Rússia. A PIPL da China (Personal Information Protection Law, em vigor desde novembro de 2021) exige localização para operadores de infraestrutura crítica de informação e para processadores de dados de alto volume. Nenhum desses regimes se importa onde seus servidores de aplicação rodam; todos se importam onde os dados pessoais são armazenados e processados.
Quando multirregional faz sentido
Multirregional se justifica quando você tem usuários geograficamente distribuídos com requisitos de latência abaixo de 100 ms, quando tem obrigações regulatórias de residência de dados em várias jurisdições ou quando o risco de queda de uma única região é inaceitável. Raramente se justifica para projetos de hobby, SaaS de baixo tráfego com usuários em uma só região ou cargas em que a complexidade de engenharia supera os ganhos de latência.
Multirregional adiciona três custos concretos. Primeiro, complexidade de engenharia: replicação de dados (eventualmente consistente ou globalmente síncrona), lógica de roteamento (geo-DNS, anycast, failover regional) e observabilidade entre regiões multiplicam a superfície operacional. Segundo, custo de infraestrutura: pelo menos o dobro de compute e armazenamento, mais taxas de trânsito entre regiões que provedores de nuvem cobram por GB. Terceiro, trade-offs de consistência: gravações globais síncronas são fisicamente limitadas pela mesma matemática de latência da seção anterior, então a maioria dos designs multirregionais aceita alguma forma de consistência eventual. As justificativas que valem esse custo: usuários reais distribuídos por continentes, onde latência de 200+ ms reduz conversão; requisitos de RTO subsegundo na recuperação de desastres; obrigações regulatórias de manter dados da UE na UE e dos EUA nos EUA simultaneamente; ou requisitos ativos de alta disponibilidade onde qualquer queda de um único datacenter deve ser invisível. A maioria das cargas de produção não precisa disso; muitos designs são superengenheirados nessa direção.
Árvore de decisão: como escolher uma região
Passo 1: identifique onde 80% dos seus usuários moram (analytics, logs de CDN, mercado-alvo esperado). Passo 2: escolha a região de hospedagem mais próxima. Passo 3: verifique se a jurisdição legal corresponde às suas obrigações de residência de dados. Passo 4: só adicione uma segunda região se o passo 1 revelar um segundo cluster de usuários a mais de 100 ms de RTT do primeiro, ou se requisitos de HA/DR exigirem.
Percorra a árvore honestamente. Para um SaaS típico focado na Europa com usuários majoritariamente na Alemanha, França, Reino Unido e Países Baixos, um único datacenter na Europa Ocidental (Frankfurt, Amsterdã ou Londres) mantém todo usuário abaixo de 30 ms de RTT e satisfaz o GDPR de forma limpa. Para um produto B2B focado nos EUA com usuários de Boston a Los Angeles, um único datacenter no leste dos EUA (Ashburn, NYC) mantém usuários da Costa Leste abaixo de 20 ms e da Costa Oeste abaixo de 80 ms — ruim para jogos, ok para a maioria dos SaaS. Para produtos genuinamente globais (web apps com usuários em todos os continentes), uma região principal mais uma CDN com presença global de borda geralmente vence rodar ativo-ativo em três datacenters. Para produtos com requisitos rígidos de residência de dados entre jurisdições (um plano de dados apenas da UE e apenas dos EUA), multirregional torna-se obrigatório, independentemente da latência.
Atalhos de conformidade: certificações que realmente importam
Procure por ISO/IEC 27001 (gestão de segurança da informação), SOC 2 Tipo II (controles operacionais auditados ao longo do tempo, não em um único momento) e PCI DSS Nível 1 (dados de pagamento) se aplicáveis. Para clientes da UE, procure acordos explícitos de processamento de dados (DPAs) sob o GDPR e uma lista clara de subprocessadores. Marketing genérico de "segurança de nível empresarial" sem certificações nomeadas é essencialmente irrelevante.
Três certificações têm peso real. A ISO/IEC 27001:2022 é o padrão internacional para sistemas de gestão de segurança da informação e exige uma auditoria independente e auditorias de vigilância contínuas. O SOC 2 Tipo II audita os controles de uma organização ao longo de uma janela de observação de 6 a 12 meses, distinguindo-o do Tipo I (ponto no tempo). O PCI DSS se aplica se você lida com cartões de pagamento; o Nível 1 é para organizações que processam mais de 6 milhões de transações/ano. Para clientes europeus, o DPA do GDPR (adendo de processamento de dados) é contratualmente vinculante e lista exatamente o que o provedor pode e não pode fazer com seus dados. Além disso, procure por relatórios de transparência (com que frequência o provedor recebe pedidos de autoridades?), uma lista pública de subprocessadores (terceiros que tocam seus dados) e garantias claras de exclusão de dados ao término do contrato. Frases genéricas como "segurança de nível bancário" ou "criptografia de grau militar" não dizem nada — o algoritmo AES-256 subjacente é o mesmo em todo lugar.