Quando eu leio “Google traz o cabo Nuvem para Portugal: Sines vai ligar-se diretamente aos EUA”, eu não vejo só uma notícia de infraestrutura. Eu vejo latência, redundância e mudanças práticas no que a gente consegue (e como consegue) entregar em aplicações reais. Segundo o Sapo.pt, o novo cabo vai ligar Sines aos EUA passando pelos Açores e pelas Bermudas — e isso mexe direto com a experiência de quem desenvolve serviços com dependência transatlântica.
O que é o cabo submarino “Nuvem” e por que ele importa para quem programa
O “Nuvem” é um cabo de fibra óptica submarina com cerca de 6900 km, com amarração garantida em Sines. A leitura importante aqui: não é “Internet via satélite”. É fibra no fundo do oceano carregando a maior parte do tráfego entre continentes.
Na minha experiência, devs subestimam a infraestrutura porque trabalham no “topo” da pilha. Mas desempenho percebido (tempo de resposta, taxa de timeouts, jitter) depende muito de coisas que acontecem antes do pacote chegar no seu servidor.
Comparação rápida: cabo x satélite x “tudo depende da cloud”
- Cabo submarino (fibra): baixa latência e alta capacidade. Ideal para tráfego contínuo e previsível.
- Satélite: latência maior por conta do caminho e do tipo de órbita. Funciona, mas costuma piorar UX e estabilidade para certos workloads.
- “A cloud resolve tudo”: a cloud ajuda no roteamento interno e em features, mas não elimina gargalos do caminho físico. Se o link transatlântico fica mais “direto”, você tende a ver ganhos.
O motivo é simples: o caminho físico muda. E quando o caminho muda, muda também a latência base e as rotas de fallback quando algo falha. Isso aparece no dia a dia como menos variância e menos timeouts “misteriosos” em integrações.
Como cabos submarinos são planejados (e onde os bugs de infraestrutura nascem)
O Sapo.pt descreve o processo: estudo do percurso com profundidade, temperatura do fundo, atividade sísmica, tráfego de pesca e cabos já existentes. Esse detalhe importa para devs porque explica por que “não é só deitar fibra”.
Na prática, o planejamento tenta reduzir riscos de falha e aumentar resiliência. Mesmo assim, cabos falham. Quando falham, o que você vê no seu sistema é um conjunto de sintomas: picos de latência, retransmissões, rotas alternativas e, em alguns casos, perda total temporária.
O que acontece antes do cabo entrar no seu grafo de rede
- Mapeamento do leito: evita áreas com maior risco.
- Escolha de rota: minimiza interferência com pesca/âncoras.
- Folga e assentamento: o cabo não é “esticado ao máximo”; ele assenta com folga calculada para acompanhar o relevo.
- Enterro próximo à costa: onde há mais risco, o cabo costuma ser enterrado.
Essa parte é relevante porque “caminho” não é abstrato. O caminho físico vira caminhos de roteamento no mundo IP. E quando o roteamento muda, seu sistema muda de comportamento — mesmo que seu código continue idêntico.
O ganho real: latência, jitter e throughput em aplicações transatlânticas
O Nuvem ser a primeira ligação direta Portugal–EUA do tipo descrito (Sines ↔ EUA via Açores e Bermudas) sugere um caminho mais eficiente. Eu costumo traduzir isso em três efeitos:
- Menos latência base: melhor para protocolos sensíveis a RTT e para uso interativo.
- Menos jitter: melhora consistência de streams, APIs síncronas e integrações.
- Mais margem de capacidade: reduz pressão quando o tráfego sobe (picos sazonais, eventos, campanhas).
Mas cuidado: “menos latência” não significa “zero problemas”. Você ainda precisa projetar seu sistema para variações. Principalmente se você roda coisas como chamadas síncronas, chains de microserviços e tarefas que esperam resposta em tempo rígido.
Implicações práticas para quem desenvolve software
- APIs: timeouts podem ser ajustados com mais confiança (mas não “zerar” timeout nunca).
- Autenticação: flows com múltiplas dependências melhoram, mas continuam dependentes de rede.
- Streaming e realtime: jitter menor ajuda na estabilidade de buffers e na negociação.
- ML/IA: treinamento distribuído pode não depender do mesmo link (muitas vezes é infra interna/region), mas inferência e chamadas a APIs externas sofrem com RTT e disponibilidade.
- Observabilidade: quando o caminho melhora, você também precisa observar se caiu a taxa de retransmissão, se mudou o perfil de latência e se diminuíram erros intermitentes.
Na Prática: como tirar proveito (sem cair em suposições erradas)
Vou te mostrar um passo a passo que eu aplico em projetos quando muda algo na rede (ou quando migramos região, encadeamos CDNs, ou começamos a depender de um novo provedor transatlântico).
1) Meça antes de “assumir”
- Separe métricas por endpoint e por tipo de operação (login, busca, checkout, inference).
- Crie histogramas de latência (não só média).
- Monitore p95/p99, taxa de timeout e erros por classe (DNS, handshake TLS, connect, read).
2) Ajuste timeouts e retries com base em distribuição
Quando a latência base cai, muita gente reduz timeouts agressivamente. Eu já vi isso causar efeito contrário: em períodos de congestionamento, o sistema vira “retry storm”. A abordagem segura é:
- Manter timeouts com folga para p99 histórico.
- Adicionar retry apenas para erros “idempotentes” e com backoff exponencial + jitter.
- Adicionar circuit breaker para proteger dependências.
3) Faça testes controlados com uma “canary”
- Escolha um pequeno percentual de tráfego.
- Meça impacto em latência e taxa de erro.
- Compare com o mesmo horário da semana anterior (sazonalidade existe).
4) Observe a camada de rede indiretamente (HTTP/TLS), sem “inventar causa”
Sem acesso ao backbone, o que você consegue é inferir. Procure por sinais como:
- queda de “connect timeout” e “TLS handshake timeout”
- menos read timeouts em picos
- mudança no perfil de latência (p95/p99)
Exemplo funcional: cliente HTTP com timeout, retries e circuit breaker
Um exemplo em Python usando httpx e uma estratégia simples com backoff. A ideia é: você aproveita melhorias de rota quando existirem, mas não quebra quando a rede oscila.
import random
import time
import httpx
def backoff(attempt, base=0.2, cap=2.0):
# backoff exponencial com jitter
delay = min(cap, base * (2 ** attempt))
return delay * (0.5 + random.random())
def is_retryable_error(exc: Exception) -> bool:
# Ajuste conforme seu caso. Aqui tratamos timeouts e conexões.
return isinstance(exc, (httpx.TimeoutException, httpx.ConnectError, httpx.NetworkError))
def get_with_retries(url: str, max_attempts: int = 3):
timeout = httpx.Timeout(connect=2.0, read=4.0, write=2.0, pool=2.0)
with httpx.Client(timeout=timeout) as client:
last_exc = None
for attempt in range(max_attempts):
try:
r = client.get(url)
r.raise_for_status()
return r.text
except Exception as exc:
last_exc = exc
if attempt == max_attempts - 1:
raise
if not is_retryable_error(exc):
raise
time.sleep(backoff(attempt))
raise last_exc
if __name__ == "__main__":
print(get_with_retries("https://example.com"))Por que isso importa aqui? Porque mesmo com cabo novo, o mundo real continua com congestionamento, falhas locais e mudanças de roteamento. O seu sistema precisa ser resiliente para o “pior momento”, não só otimizado para o “caso ideal”.
Erros Comuns: o que devs costumam fazer (e que quebra quando a rede muda)
1) Ajustar timeouts sem observar p99
Erro clássico: reduzir timeout para “sentir” menor latência. Sem histogramas, você só mede o que parece bom. A rede tem caudas longas. Troque média por p95/p99.
2) Retry sem idempotência
Retry em operações que cobram, criam pedido ou disparam side effects pode duplicar ações. Se você não tiver idempotency key, retry sem disciplina vira dívida técnica operacional.
3) Ignorar DNS/TLS como parte do RTT
Muita gente olha “latência HTTP” como uma coisa só. Mas “connect” e “TLS handshake” são etapas separadas. Mudanças de rota podem afetar especialmente essas fases.
4) Não usar observabilidade por erro
Se seu dashboard só mostra “HTTP 500”, você perde a causa. Use métricas por etapa: resolve, connect, handshake, read, timeout.
5) Tratar jitter como ruído e não como sinal
Jitter afeta buffers, retries em cascata e deadlines. Melhorar a rede ajuda, mas você ainda precisa de estratégia: timeouts inteligentes, circuit breaker e controle de concorrência.
FAQ
O cabo submarino substitui a Cloud ou melhora automaticamente qualquer aplicação?
Não. Ele melhora o caminho físico do tráfego entre regiões, mas o impacto depende do seu roteamento, do provedor, do cache/CDN e do perfil do seu tráfego. Você precisa medir.
Se a latência diminuir, posso remover retries e timeouts?
Não. A rede continua variando e cabos podem falhar. Eu ajusto timeouts/retries com base em p95/p99 e introduzo circuit breaker para proteger dependências.
Como o cabo afeta aplicações de IA (inferência e chamadas a APIs)?
Inferência feita via API externa tende a se beneficiar de menor RTT e menos variação. Treinamento distribuído depende mais do seu desenho de infraestrutura. Ainda assim, integrações síncronas externas sofrem com latência e estabilidade.
Qual a diferença prática entre “direto” e “indireto” entre Portugal e EUA?
Em geral, “direto” significa menos saltos e um caminho mais eficiente (menos atraso acumulado). Mas roteamento é dinâmico; você pode ver ganhos progressivos dependendo de como as redes passam a atender o tráfego.
O que eu devo monitorar depois que o cabo entrar em operação?
Latência por percentil, taxa de timeouts, erros por etapa (connect/handshake/read), retransmissões quando possível (no nível do sistema) e comportamento de circuit breaker/retries.
Segundo o Sapo.pt, a entrada em funcionamento do Nuvem está prevista para este ano, com amarração em Sines. Quando isso acontecer, o melhor jeito de “transformar notícia em valor” é simples: medir, ajustar com disciplina e testar com rollout controlado.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.