Latência é o tempo que um dado leva para ir de um ponto ao outro e voltar — o RTT (Round-Trip Time). Em cloud, ela determina se sua aplicação é rápida ou frustrante, e entender suas causas é o primeiro passo para resolver problemas reais de performance.
O que é latência e por que importa
Imagine que você tem uma aplicação de atendimento ao cliente rodando em cloud, e os atendentes reclamam que o sistema “trava” quando abrem o histórico de um cliente. O servidor tem CPU e memória de sobra. O banco de dados responde rápido nas queries de teste. Mas na prática, cada clique leva 2-3 segundos.
O culpado frequentemente não é processamento — é latência. Cada interação entre o navegador do atendente e o servidor, ou entre o servidor de aplicação e o banco de dados, soma milissegundos. Se uma página precisa de 15 chamadas para carregar e cada uma tem 150ms de latência, o resultado é 2,25 segundos de espera — mesmo que o processamento de cada chamada leve apenas 10ms.
Latência e velocidade (bandwidth) são frequentemente confundidas. Bandwidth é a capacidade do link — quantos dados podem trafegar por segundo. Latência é a demora antes de a primeira resposta chegar. Você pode ter um link de 10Gbps com 200ms de latência para um destino distante: é rápido para transferir arquivos grandes, mas miserável para aplicações interativas que fazem muitas chamadas pequenas.
As causas de latência em cloud
Entender de onde vem a latência ajuda a escolher a solução certa:
Distância física é a causa mais fundamental e mais negligenciada. A luz viaja pela fibra óptica a cerca de 200.000 km/s — isso significa que entre São Paulo e Los Angeles (9.000km), o mínimo físico possível de latência é ~45ms só de ida. Por isso, escolher um datacenter próximo dos seus usuários não é detalhamento técnico — é decisão de arquitetura com impacto direto na experiência.
Congestionamento de rede acontece quando múltiplos fluxos competem pela mesma capacidade de link. Em internet pública, isso é imprevisível e varia com o horário. Um link saturado a 90% de utilização tem latência muito maior do que o mesmo link a 50%.
Processamento nos roteadores — cada salto (hop) que um pacote dá entre roteadores adiciona latência de processamento. Traceroute mostra esses saltos. Uma rota com 15 hops tem mais latência de roteamento do que uma com 6, mesmo com a mesma distância física.
Serialização é o tempo que leva para colocar os bits no link. Para links lentos ou pacotes grandes, esse tempo é relevante. Para um link de 1Gbps enviando pacotes de 1500 bytes, o tempo de serialização é de ~12 microssegundos — negligenciável. Para um link de 10Mbps, o mesmo pacote leva ~1,2ms só para ser serializado.
Latência de aplicação às vezes é confundida com latência de rede. Query de banco de dados mal indexada, N+1 queries, código que faz chamadas síncronas desnecessárias — tudo isso aparece como “lentidão” mas a causa está no código, não na rede.
Como medir latência na prática
Ping é o ponto de partida. ping servidor.empresa.com mostra o RTT médio para o destino. Simples e direto. A limitação é que ping usa ICMP, que algumas redes bloqueiam ou de-priorizam — então latência alta no ping não significa necessariamente que aplicações TCP terão a mesma latência.
Traceroute (no Windows: tracert) mostra cada salto entre você e o destino, com a latência de cada um. Permite identificar onde a latência está concentrada — se o problema está no trecho entre o seu escritório e o ISP, entre ISPs, ou próximo ao destino. No Linux/Mac: traceroute -n destino.com (o -n evita resolução reversa de DNS que atrasa a execução).
MTR (My TraceRoute) combina ping e traceroute num relatório contínuo, mostrando estatísticas de perda de pacotes e variação de latência (jitter) em cada hop. É a ferramenta preferida de administradores de rede para diagnóstico: mtr -n destino.com.
Ferramentas de monitoramento como Grafana + Prometheus, Datadog, New Relic ou Zabbix permitem monitorar latência continuamente ao longo do tempo — essencial para detectar padrões (degradação em horário específico, após deploy, correlacionada com aumento de tráfego).
Latência aceitável por tipo de aplicação
Nem toda aplicação precisa do mesmo nível de latência. A tabela abaixo é um referencial prático:
| Tipo de aplicação | Latência aceitável | O que acontece além disso |
|---|---|---|
| Banco de dados transacional (app → DB) | < 1–5ms | Queries simples ficam lentas, throughput cai |
| VDI / Desktop virtual | < 20ms | Usuário percebe atraso no teclado e mouse |
| VoIP / videoconferência | < 150ms (one-way) | Sobreposição de fala, eco, experiência ruim |
| Aplicação web corporativa | < 100ms (ida) | Páginas que parecem “pesadas” para o usuário |
| API de terceiros (não crítico) | < 500ms | Aceitável se não for caminho crítico |
| Backup / replicação | Flexível | Não é interativo; latência alta é tolerável |
Como reduzir latência em cloud
Escolha o datacenter certo: para usuários no Brasil, datacenter no Brasil. Para aplicação com usuários no interior de SP, datacenter em São Paulo reduz latência muito mais do que um em outro estado. É a intervenção com maior ROI na maioria dos casos — e começa na hora de escolher o provedor de cloud.
CDN para conteúdo estático: imagens, CSS, JavaScript, vídeos servidos de POPs próximos ao usuário. Reduz drasticamente a latência percebida sem mudar a arquitetura do backend.
Edge computing: para aplicações onde latência ultrabaixa é crítica, processar na borda (próximo ao usuário) em vez de enviar tudo para o servidor central. Cloudflare Workers, AWS Lambda@Edge e arquiteturas similares permitem isso.
Otimize as chamadas da aplicação: menos chamadas de rede com mais dados cada (batching), cacheamento de resultados frequentes, conexões keep-alive em vez de abrir nova conexão TCP a cada requisição, HTTP/2 ou HTTP/3 para paralelizar requisições.
Reduza o número de hops: use link direto ou VPN dedicada para reduzir o número de roteadores entre pontos críticos, especialmente para tráfego app → banco de dados.
Monitore antes de tentar otimizar: sem métricas de latência por componente (rede, banco de dados, código), você corre o risco de otimizar o lugar errado. Use APM (Application Performance Monitoring) para saber onde o tempo realmente está sendo gasto.
Os datacenters da Adentro em Osasco/SP, Vinhedo/SP e Porto Alegre/RS são conectados ao IX.br e a principais carriers, garantindo latência otimizada para os principais destinos no Brasil. Fale com nossa equipe para uma avaliação técnica do seu ambiente.