Posted on dev.to · Quant / Backend Engineering
Reading time: 6‑8 min
🏷️ Tags: #api #quantdev #marketdata #hongkongstocks #usstocks #websocket #debugging
Problem: Why Are My API Market Prices Mismatched?
When building quant back‑testers, paper‑trading simulators or real‑time dashboards, we frequently consume real‑time data via stock quote APIs covering A‑Shares, Hong Kong stocks and US stocks.
A very common debugging scenario: your application runs with zero exceptions, but the quote values you receive consistently drift several seconds away from mainstream broker apps.
I’ve spent countless hours reviewing my own business logic, checking local network status and tracing request pipelines, convinced I must have introduced a bug somewhere. After repeated production debugging work, we found the real root cause: latency within the upstream market‑data feed.
What makes this issue extra tricky: latency symptoms differ across markets. A‑Shares, Hong Kong stocks and US stocks each come with unique trading rules and cross‑border network constraints. Generic one‑size‑fits‑all latency checks will produce false positives and send you down the wrong debugging path.
Most developers instinctively blame local network instability whenever prices do not align. While network jitter can contribute to delays, it is only one factor. To accurately diagnose lag from a stock quote API you must rely on timestamps — do not only compare raw price figures.
Core Concept: Event Time vs Receive Time — Real Latency vs False Signals
✨ Quick dev‑to callout block
Don’t judge latency purely by price differences. Timestamps are your source of truth.
Two timestamp fields form the foundation of your latency diagnostics:
- Event Time: The authoritative timestamp generated by the exchange when an order matches and a tick record gets created. This time originates on the trading venue itself.
- Receive Time: The local timestamp on your server the moment your backend receives the pushed quote payload from the API provider.
Subtract Event Time from Receive Time. The millisecond result is your true end‑to‑end transmission latency.
⚠️ Critical gotcha
If your stock quote API only returns Receive Time and does not expose the exchange‑generated Event Time, you lose your objective baseline. You can no longer objectively verify whether market data is delayed. This mistake trips up many developers integrating Hong Kong stocks and US stocks market feeds.
Three Practical Techniques to Verify Quote‑Feed Latency
These three approaches are battle‑tested from our production debugging workflow. They do not require heavy infrastructure, and work great for side‑projects, personal prototypes, research pipelines and small‑scale production workloads.
1. Log timestamp deltas and watch latency jitter
Every time your app receives an incoming tick message, persist both Event Time and local Receive Time, and continuously compute their difference.
- Latency stays inside a stable narrow range → your market‑data link is healthy.
- Latency has large, erratic spikes → strong sign of instability inside the upstream quote delivery pipeline.
2. Cross‑validate with two independent stock quote APIs
Run two separate connections to unrelated market‑data vendors in parallel. Compare tick snapshots for identical symbols across identical time windows.
If one data source consistently lags behind the other by a predictable offset, the problem lives inside that provider’s push mechanism — not inside your application source code.
3. Inspect price‑tick sequence continuity
Healthy real‑time market data evolves in small incremental price movements.
If you see sudden huge price jumps with no intermediate ticks in‑between, packet loss is highly likely. What you observe is synthetic back‑filled data reconstructed on the API provider’s backend — genuine real‑time streamed data never arrived.
Market‑Specific Edge Cases: A‑Shares, Hong Kong Stocks, US Stocks
Trading mechanisms and cross‑border network conditions vary widely, so latency symptoms cannot be interpreted uniformly.
| Market | Common source of latency / misinterpretation | Debugging guidance |
|---|---|---|
| A‑Shares | Cross‑border network routing detours | Monitor jitter amplitude of local Receive Time
|
| Hong Kong Stocks | Large price swings during 9:00‑9:30 opening auction | Exclude auction window from latency alerts; avoid mistaking normal auction volatility for data lag |
| US Stocks | Pre‑market / after‑hours data not subscribed | Double‑check API permissions. Many “latency” complaints are simply missing extended‑hours tick data |
📝 Note for developers
Most stock quote APIs for US stocks only stream regular‑trading‑session ticks by default. Pre‑market and after‑hours trades are not pushed to your client. Developers frequently misinterpret missing extended‑hours data as feed latency.For Hong Kong stocks, wild price swings in opening auction are part of exchange matching logic. Naive generic latency‑detection logic will flood monitoring with meaningless false‑positive alerts.
For our internal multi‑market validation tasks, we use AllTick API. One integration covers A‑Shares, Hong Kong stocks and US stocks, removing operational overhead of maintaining separate connections to multiple market‑data vendors.
Code Snippet: Runnable WebSocket Demo for Multi‑Market Latency Measurement
dev.to readers can copy‑paste this demo directly to test latency for A‑Shares, Hong Kong stocks and US stocks. The script subscribes to real‑time ticks and prints per‑tick transmission latency for local debugging.
import websocket
import json
import time
WS_URL = "wss://quote.alltick.co/quote-stub"
TOKEN = "your_token_here"
def on_message(ws, message):
data = json.loads(message)
event_time = data.get("tick_time")
receive_time = int(time.time() * 1000)
if event_time:
delay = receive_time - int(event_time)
print(f"symbol={data.get('code')} delay_ms={delay}")
def on_open(ws):
sub_msg = {
"cmd_id": 22004,
"seq_id": 1,
"trace": "sub-1",
"data": {
"symbol_list": [
{"code": "700.HK"},
{"code": "AAPL.US"},
{"code": "600519.SH"}
]
}
}
ws.send(json.dumps(sub_msg))
ws = websocket.WebSocketApp(
f"{WS_URL}?token={TOKEN}",
on_open=on_open,
on_message=on_message
)
ws.run_forever()
Debugging tips
After running the script, persist delay_ms output into your logging system. Chart latency over time with a simple line plot; sharp spikes caused by upstream‑link anomalies become immediately visible.
A key lesson learned in production: do not panic over isolated one‑off millisecond‑scale delays. Latency fluctuation range is far more important than individual latency samples.
- Stable latency band: Feed is trustworthy for backtesting and paper‑trading.
- Violent unstable latency swings: Tick‑data time ordering is compromised, which will materially skew quant‑strategy results and requires deeper investigation.
I will keep sharing new troubleshooting patterns and edge‑case observations as I encounter them in live production environments.
When you are building latency‑monitoring pipelines for market‑data feeds, APIs that natively expose exchange‑origin timestamps eliminate massive amounts of custom time‑alignment boilerplate. AllTick API exposes raw tick_time field out‑of‑the‑box. Without extra time‑conversion logic, engineers can quickly implement latency statistics and anomaly‑detection pipelines across A‑Shares, Hong Kong stocks and US stocks. This frees up engineering bandwidth so you can focus on core quant business logic instead of tedious cross‑market data‑alignment work.
Have you ever misread exchange‑specific behaviour or missing‑data events as latency while working with stock quote APIs for Hong Kong stocks and US stocks?
Share your debugging war stories, mistakes, or favourite tricks in the comments! I read all replies.
Top comments (0)