Market data is not the edge (but bad data will kill yours)
Clean feeds, rate limits, and multi-exchange plumbing do not print money — they stop you from lying to yourself while you search for EV+.
market-data · bots · engineering · advice
We sell and build market-data tooling. That makes this post slightly awkward, which is useful. If we claim the feed is the alpha, we are lying. If we claim the feed does not matter, we are also lying.
Will better data make you profitable?
Not by itself.
Profit comes from a strategy with positive expected value after costs, sized so you survive variance. Data is an input. A clean input can still feed a bad idea. A dirty input can destroy a good one.
Think of data like brakes and headlights on a car. They do not choose the destination. They decide whether you crash on the way.
What “bad data” actually looks like in bots
Not Hollywood. Mostly boring failure modes:
- Stale books presented as live
- Partial REST snapshots treated as full state
- Rate-limit 429s retried into a thundering herd
- Clock skew so your “signal time” is a fantasy
- Venue A vs venue B timestamps you casually merge
- Silent gaps after reconnect that your strategy never sees
Your backtest then becomes a novel: well written, fictional.
Public data vs private data (keep them straight)
| Kind | Examples | Who holds the keys |
|---|---|---|
| Public | Tickers, books, trades, funding, open interest | Often no user secrets; still subject to IP / weight limits |
| Private | Balances, open orders, fills, positions | Your exchange keys — should stay under your control |
A hosted market-data path for public endpoints is an ops choice. It is not a reason to upload withdrawal-capable keys to a stranger’s box.
If a product blurs that line, walk away.
Rate limits are part of the strategy
People treat rate limits as an annoyance. They are market microstructure for your code.
If your edge assumes:
- refreshing 20 books every 100 ms from one IP, or
- fan-out across ten venues with naive clients, or
- “just retry until it works,”
…then your edge includes an assumption about exchange goodwill. That assumption expires.
Design for:
- Caching what can be cached
- Backoff that is not a DDoS on yourself
- Clear budgets per account / IP / venue
- Degraded mode when data is late (usually: do not trade)
No data > wrong data. Flat is better than confident and wrong.
Multi-exchange is not free alpha
More venues can mean:
- More opportunities
- More basis / structure to study
- More ways to sample an idea
They also mean:
- More fee schedules
- More reject reasons
- More clocks, more gaps, more ops
Start with one venue, one path, one rule. Add markets when the first path is boring and measured — not when you are bored.
Research lies that look like engineering progress
These feel productive and often are not:
- Building a perfect unified symbol map before you have one working strategy
- Collecting every candle since genesis for a rule you cannot explain
- Spending a month on micro-latency when your idea is daily mean reversion
- Switching languages “for speed” while the PnL bug is a fee sign error
Engineering should serve a hypothesis. If there is no hypothesis, you are collecting stamps.
What good plumbing enables
When public data is reliable enough:
- You spend time on edge and risk, not on ban avoidance
- Logs match what the market actually did
- Paper and live disagree less often for dumb reasons
- You can kill strategies based on truth, not on feed artifacts
That is the bar. Not “alpha as a service.”
How we think about our own tools
We built the library and the market-data service so we (and people like us) can:
- Touch more markets with lower resource cost
- Reduce copy-paste when adding a venue
- Keep public traffic manageable (rate limits, proxies)
- Keep private orders under the trader’s own keys
If that matches a problem you actually have:
- Market Data API — public exchange data through a hosted proxy
- nexrade — multi-exchange Python trading library
- nexrade-cache — local Redis-compatible cache (including Windows, no WSL)
If your problem is “I don’t have an edge,” no API fixes that. Go back to expectancy, costs, and small size.
Clean data will not make you rich. Dirty data will make you confidently wrong.
Build slowly. Measure after fees. Assume the feed can lie — then make lying harder.
That is how we still trade — and how we still write bots.
Want to try the path this note describes? Create a free API key, or return to the full list of notes.