Dynamically Tune WebSocket Heartbeat Intervals by Network Latency for Python Stock‑Market APIs

Intro

For a FinTech course group assignment, our team built a small cloud‑deployed market‑data SaaS prototype. We used Python stock‑market APIs and WebSockets to ingest continuous tick‑based real‑time market streams.

To get our prototype working quickly, we hard‑coded a fixed heartbeat ping interval. Our initial assumption was simple: regularly sending ping packets would keep the WebSocket connection alive.

Everything worked fine locally, but issues surfaced after deployment to cloud lab environments. Unlike controlled local‑network conditions, public internet connections suffer from random jitter. We found cases where the market feed had already stopped silently, yet our application kept running, treating stale data as valid input for simulation and aggregation logic.

This experience drove home a key observation. Heartbeats are an easy‑overlooked detail for WebSocket long‑lived connections, but they directly determine data continuity and overall reliability for FinTech market‑data applications.

What’s wrong with static heartbeat values

Many beginner demos for Python stock APIs use fixed‑interval heartbeats — pinging every 10 s, 30 s, or 60 s. This implementation is trivial and works well for local development.

Real‑world public networks have constantly‑changing round‑trip latency, exposing two clear downsides to static configuration:

• Low‑latency scenarios: Too‑frequent ping messages create redundant traffic, wasting bandwidth and burning through API‑call quotas.
• High‑latency / jitter‑prone scenarios: A long static heartbeat slows failure detection. Broken connections can remain undetected for long periods.

Hard‑coded timings cannot adapt to shifting network conditions. To improve connection resilience, heartbeat intervals need to adjust dynamically based on real‑time link quality.

Adaptive heartbeat: tune intervals using measured round‑trip latency

The core concept behind dynamic heartbeat tuning is sampling WebSocket round‑trip time (RTT).

Record the timestamp when you send a ping payload. Capture the timestamp when the corresponding pong response arrives from the server. The difference gives you current network RTT. Collect multiple latency samples to evaluate link health and adjust your heartbeat interval accordingly.

We used this simple rule set during lab testing:

• Average latency 100‑500 ms → heartbeat interval: 30 seconds
• Average latency > 500 ms → heartbeat interval: 10 seconds (increase failure‑check frequency)
• Average latency < 100 ms → heartbeat interval: 60 seconds (reduce network overhead)

When latency is low we reduce heartbeat frequency to lighten network load. When latency rises we shorten intervals to spot anomalies faster. Compared with static values, this adaptive approach is much better suited for real‑time market‑data workloads.

During lab validation we pulled real‑time tick streams via AllTick API and integrated heartbeat detection alongside regular market‑message consumption.

import websocket
import json
import time

def on_open(ws):
    sub_req = {
        "action": "subscribe",
        "source": "alltick",
        "symbol": "600000",
        "type": "trade"
    }
    ws.send(json.dumps(sub_req))

def heartbeat_check(ws):
    start = time.time()
    ws.send(json.dumps({"action": "ping"}))
    rtt = (time.time() - start) * 1000
    if rtt < 100:
        return 60
    elif rtt < 500:
        return 30
    else:
        return 10

if __name__ == "__main__":
    ws_app = websocket.WebSocketApp("wss://api.alltick.co/stock/websocket", on_open=on_open)
    ws_app.run_forever()

⚠️ Note: Minimal demo snippet for educational use. For robust assignments or production prototypes: compute smoothed moving‑average latency to filter transient network spikes. Run heartbeat logic on a separate thread so heavy incoming market messages cannot block heartbeat processing.

Practical engineering takeaways for reliability & cost

Sending heartbeats more often does not guarantee a more stable connection. Excessive pings bloat network traffic; overly‑sparse intervals extend the window where outages go unnoticed.

Team debugging takeaway: Don’t modify heartbeat intervals in reaction to a single latency spike. Adjust settings only after sustained latency shifts across multiple heartbeat cycles — this delivers far more stable runtime behaviour.

Adaptive heartbeat logic is only one part of connection maintenance. Always pair it with auto‑reconnection logic. When a WebSocket drops, your code must re‑establish the session and restore market subscriptions. Without this step data ingestion stays offline even after network recovery.

When building FinTech market‑data tooling, developers often focus heavily on raw data‑fetching speed. Even so, long‑connection reliability deserves equal attention. Dynamic heartbeat adaptation adds little implementation overhead while drastically improving fault tolerance on unstable public networks. Solid low‑level connectivity lays a stable foundation for upstream simulation, factor calculation and data‑aggregation workflows.