Short Polling: The Impatient Client Pattern

Short Polling: The Impatient Client

Like a child repeatedly asking "Are we there yet?" on a long car journey, short polling constantly asks the server for updates at fixed intervals - regardless of whether new data exists. Simple to implement, but often wasteful.

Key Concepts

1. Fixed Interval Requests: Client sends requests every N seconds (typically 1-10s)
2. Immediate Server Response: Server responds immediately - either with data or "nothing new"
3. Timer-Based: A simple setInterval controls the polling frequency
4. Stateless: Each request is independent; no connection maintained between polls

The critical insight: most requests return empty responses because data changes less frequently than the polling interval.

How It Works

Client                          Server
  |                               |
  |-------- GET /api/data ------->|
  |                               | (Process immediately)
  |<------- 200 OK (data) --------|
  |                               |
  |         Wait 3 seconds        |
  |                               |
  |-------- GET /api/data ------->|
  |                               | (Process immediately)
  |<------ 204 No Content --------|
  |                               |
  ... (repeats indefinitely) ...

Implementation

import time
import requests

def short_poll(url, interval=3):
    """Poll server at fixed intervals."""
    while True:
        response = requests.get(url)
        if response.status_code == 200:
            data = response.json()
            if data.get('has_updates'):
                handle_update(data)
        time.sleep(interval)

The Efficiency Problem

Request Frequency

• 1 second interval: 3,600 requests/hour
• 3 second interval: 1,200 requests/hour
• 10 second interval: 360 requests/hour

Wasted Bandwidth

In typical scenarios, 70-90% of requests return no new data. Each empty response still transfers ~1KB of HTTP headers.

Average Discovery Latency

With a 3-second interval, data sits waiting for an average of 1.5 seconds before the client discovers it.

When to Use

Good Use Cases

• Simple status checks - Server health, build status, queue length
• Infrequent updates - Weather data, delayed stock quotes
• Quick prototypes - When simplicity matters more than efficiency

Poor Use Cases

• Real-time requirements - Chat, gaming, collaboration
• High-frequency updates - Trading, live sports
• Resource-constrained - Mobile apps, metered connections

Related concepts