How to Route Real-Time Gold and Silver Prices from a Unified WebSocket Stream

When I first connected to a precious metals WebSocket API, I expected to get a clean stream of prices. What I actually got was a firehose of mixed ticks—gold, silver, platinum—all arriving through the same callback. If you’ve ever tried to build a trading bot or a custom chart, you know this is a recipe for disaster. In this post, I’ll share how I solved the problem with a few lines of Python and a clear mapping strategy.

The scenario: You have one WebSocket URL that pushes quotes for multiple metals. You need to separate them so you can update different UI components, run independent strategies, or store them in distinct database tables. The data pain point: every message uses the same JSON structure, and the only differentiator is a field like symbol. If you don’t act on it immediately, everything gets mixed up.

Identify Assets via the Symbol Field

Start by checking the API docs for the field that carries the instrument code. Usually it’s symbol, but instrumentId or type are also used. Here’s a typical reference table:

Field	Description	Example
symbol	Asset code	XAUUSD, XAGUSD
instrumentId	Internal platform ID	1001, 1002
type	Asset class	gold, silver

I turn this into a dictionary mapping each symbol to a human-readable category:

asset_map = {
    "XAUUSD": "gold",
    "XAGUSD": "silver",
    "XPTUSD": "platinum"
}

Buffer Messages by Type

Because these streams are high-frequency, I avoid processing every tick individually. Instead, the WebSocket callback just updates an in-memory store that is already grouped by asset type:

# Keep the hot path extremely light
def on_message(msg):
    symbol = msg['symbol']
    price = msg['price']
    asset_type = asset_map.get(symbol, "unknown")
    cache[asset_type][symbol] = price

Then, a background timer fetches the latest prices from cache["gold"] and cache["silver"] separately and does the actual work—like computing indicators or rendering charts. The key benefit is complete isolation: your gold logic never touches a silver tick.

Subscribe Selectively

Most APIs allow you to specify which symbols you want. I always trim the list to only what I need. Some providers even support batch subscription by asset_type, which slashes unnecessary traffic even further.

When I tested AllTick’s WebSocket, the symbol field worked exactly as expected for distinguishing metals. Here’s a minimal, runnable snippet:

import websocket
import json

def on_message(ws, message):
    data = json.loads(message)
    symbol = data['symbol']
    print(f"{symbol} real-time price: {data['price']}")

ws = websocket.WebSocketApp("wss://api.alltick.co/ws",
                            on_message=on_message)
ws.run_forever()

With this setup, gold and silver prices flow through the same connection but remain completely independent in your application logic.

Handle Disconnects and Bad Data

I always add reconnection with exponential backoff and a guard clause that checks if symbol exists. If not, the message is skipped. This prevents a single malformed packet from breaking the whole stream.

Wrapping Up

By combining a simple mapping dictionary, type-bucketed caching, and tight subscriptions, you can turn a messy, mixed stream into a set of clean, per-asset data channels. It’s a small engineering effort that pays off every time you add a new metal or a new strategy. If you’re working with WebSocket market data, give this pattern a try—it’s lightweight, scalable, and keeps your codebase sane.