Short Polling: o que é, como funciona e onde é usado

O que é Short Polling

Short Polling é um padrão de comunicação onde o cliente envia periodicamente requisições HTTP ao servidor com um intervalo predefinido, e o servidor processa cada requisição de forma síncrona e retorna o resultado imediatamente. O intervalo de polling é definido no lado do cliente usando temporizadores e geralmente varia de 1 a 60 segundos dependendo dos requisitos de atualização dos dados.

Short Polling é cronologicamente o primeiro mecanismo para organizar a comunicação em tempo real em aplicações web. No início dos anos 2000, antes da segunda geração do XMLHttpRequest, as páginas web usavam <meta http-equiv="refresh"> ou recarga periódica de iframes para atualizar o conteúdo. Com o advento da tecnologia AJAX (Asynchronous JavaScript and XML) em 2005, o Short Polling tornou-se a abordagem padrão para atualizar dados sem recarregar completamente a página.

Arquitetura do Short Polling

A arquitetura do Short Polling inclui três componentes: um temporizador do cliente, uma requisição HTTP e um manipulador do servidor. O cliente inicia um temporizador de intervalo e, a cada ativação, uma requisição GET é enviada ao servidor. O servidor consulta um banco de dados ou outra fonte, forma uma resposta e a retorna imediatamente ao cliente. O cliente atualiza a interface e aguarda a próxima ativação do temporizador. Este ciclo se repete indefinidamente enquanto a aplicação estiver ativa.

O problema das requisições redundantes

O principal problema do Short Polling são as inevitáveis requisições vazias. Se os dados mudam com pouca frequência, a maioria das requisições retorna um resultado "sem alterações", desperdiçando largura de banda da rede e tempo de CPU no processamento. Com 10.000 clientes com intervalo de polling de 5 segundos, o servidor recebe 2.000 requisições por segundo — uma parte significativa das quais é inútil se a frequência de atualização for de 1 evento por minuto.

Como funciona o Short Polling

Short Polling funciona em um ciclo simples: o cliente define um temporizador de intervalo com um período determinado (por exemplo, 5000 ms). A cada ativação do temporizador, o cliente forma uma requisição HTTP GET ao endpoint do servidor, geralmente com um parâmetro de timestamp da última atualização. O servidor recebe a requisição, verifica se há novos dados após o timestamp especificado e retorna uma resposta — seja com novos dados ou com um indicador de que não há atualizações.

Um parâmetro crítico de configuração do Short Polling é o intervalo de polling. Um intervalo muito curto (menos de 3 segundos) cria alta carga no servidor e na rede. Um intervalo muito longo (mais de 30 segundos) reduz a atualidade dos dados. O intervalo ideal depende do cenário: para painéis de monitoramento — 5–15 segundos, para feeds de notícias — 30–60 segundos, para alertas críticos — 1–3 segundos. A escolha do intervalo é sempre um compromisso entre a atualidade dos dados e a carga na infraestrutura.

Intervalo de polling adaptativo

Para reduzir a carga durante a inatividade, utiliza-se o intervalo adaptativo: se várias requisições consecutivas retornarem resultado vazio, o intervalo aumenta (por exemplo, de 5 para 15 segundos). Quando novos dados aparecem, o intervalo é redefinido para o valor mínimo. O algoritmo de backoff exponencial (exponential backoff) permite reduzir o número de requisições vazias em 3–5 vezes durante atualizações pouco frequentes.

Exemplo de implementação de Short Polling em JavaScript

Vejamos uma implementação de Short Polling do lado do cliente usando setInterval e Fetch API. A função recebe a URL do endpoint e o intervalo de polling em milissegundos.

function startPolling(url, intervalMs) {
    const lastTimestamp = new Date().toISOString();

    const timerId = setInterval(async () => {
        try {
            const params = new URLSearchParams({
                since: lastTimestamp
            });
            const response = await fetch(url + "?" + params);
            const data = await response.json();

            if (data.updates && data.updates.length > 0) {
                renderUpdates(data.updates);
                console.log("Recebido", data.updates.length, "updates");
            }
        } catch (error) {
            console.error("Falha no polling:", error);
        }
    }, intervalMs);

    return timerId;
}

const timer = startPolling("/api/updates", 5000);
// clearInterval(timer) para parar

O código cria um intervalo de polling de 5 segundos e passa o timestamp da última atualização ao servidor. O servidor pode usar este parâmetro para filtrar dados e retornar apenas novos registros, reduzindo a quantidade de informação transmitida. A função retorna o identificador do temporizador para possibilitar a parada do polling.

Parte do servidor do Short Polling

A implementação do lado do servidor para Short Polling é extremamente simples — é um endpoint REST comum que aceita requisições GET e retorna uma resposta JSON com o estado atual ou dados alterados após o timestamp especificado.

const express = require("express");
const app = express();

let items = [];

app.get("/api/updates", (req, res) => {
    const since = req.query.since;
    const filtered = items.filter(item => item.timestamp > since);
    res.json({ updates: filtered });
});

app.listen(3000);

O servidor recebe o parâmetro since e filtra os registros cujo timestamp excede o valor especificado. Esta abordagem minimiza a quantidade de dados em cada resposta, retornando apenas alterações incrementais. Quando não há novos dados, o servidor retorna um array vazio e o cliente continua o polling conforme programado.

Short Polling vs Long Polling

Short Polling e Long Polling resolvem o mesmo problema — a entrega de dados do servidor ao cliente — mas diferem drasticamente em eficiência. Short Polling usa intervalo fixo de requisições, criando carga previsível, enquanto Long Polling mantém a conexão aberta até que um evento ocorra, minimizando o número de respostas vazias.

A escolha entre técnicas depende da frequência de atualizações dos dados. Se os eventos ocorrem mais de uma vez a cada 10 segundos — ambas as abordagens geram carga comparável, e Short Polling pode ser mais simples. Se os eventos são raros (horas ou minutos entre alterações) — Long Polling é preferível, pois não cria requisições vazias. Para cenários intermediários, a escolha depende das limitações de infraestrutura e da possibilidade de usar WebSocket.

Quando usar Short Polling

Short Polling é usado em cenários onde os requisitos de atualidade dos dados são baixos e a simplicidade de implementação tem prioridade sobre a eficiência. Os casos mais típicos são painéis administrativos internos, sistemas de monitoramento com baixa frequência de alertas e aplicações onde um atraso de 15–30 segundos é aceitável.

• Painéis de monitoramento — painéis com métricas que atualizam a cada 10–30 segundos, sem exigir reação instantânea a mudanças.
• Páginas de status — páginas de verificação de disponibilidade de serviços onde os dados atualizam a cada 30–60 segundos e o atraso não é crítico.
• Relatórios analíticos — sistemas internos de análise com coleta periódica de dados onde a atualidade de até 1 minuto é aceitável.
• Jogos simples — jogos multijogador por turnos sem requisitos de tempo real, onde o turno atualiza a cada poucos segundos.
• Testes — cenários de teste de carga e depuração onde Short Polling é usado como método de polling de referência para comparação com outras técnicas.

Limitação importante — Short Polling não é adequado para aplicações críticas em termos de tempo (terminais de trading, sistemas de alerta de emergência) onde mesmo um atraso de 1 segundo é inaceitável. Em tais cenários, é necessário usar WebSocket, Server-Sent Events ou Long Polling. Ao projetar um sistema com Short Polling, deve-se calcular o orçamento de requisições: com 1.000 clientes com intervalo de 5 segundos, o servidor processa 12.000 requisições por minuto, o que requer uma base de recursos correspondente.