If you want to show price differences across exchanges, you’re building an arbitrage dashboard
“Create a website which can show the price difference between crypto exchanges. I need at least 5 exchanges price per second.”
That sounds simple.
Pull 5 prices.
Display them.
Refresh every second.
But if you want it to be correct, stable, and scalable - it becomes a real market data problem.
Let’s break down how to build it properly.
What you’re actually building
At a minimum, your system needs to:
- Collect real-time prices from 5+ exchanges
- Normalize symbols (BTCUSDT ≠ XBTUSD ≠ BTC-USD)
- Align timestamps
- Compute spread differences
- Update your frontend at least once per second
- Stay stable during volatility
This is not just a UI task.
It’s a real-time market data pipeline.
Step 1: Decide what “price” means
Before writing any code, answer this:
Which price are you comparing?
You have options:
- Last trade price
- Best bid
- Best ask
- Mid price ((bid + ask)/2)
- VWAP
If you use last trade, you may compare stale prices.
If you use best bid/ask, you’re comparing executable prices.
For arbitrage visibility, best bid and best ask are usually better than last trade.
Step 2: Architecture for per-second updates
You have two main options:
Option A: REST polling every second
Option B: WebSocket streaming
REST polling (simpler, not scalable)
Every second:
- Call 5 exchange APIs
- Parse responses
- Compute spread
- Push to frontend
Problems:
- Rate limits
- Latency differences
- Inconsistent formats
- Scaling becomes painful
WebSocket streaming (recommended)
- Maintain persistent connections
- Subscribe to quotes or trades
- Update in-memory cache
- Push updates to frontend
This gives you:
- Lower latency
- Consistent updates
- Better scalability
If you want per-second refresh, WebSocket streaming is the correct approach.
Step 3: Don’t normalize it yourself (use normalized data)
Different exchanges use different:
- Symbol formats
- Decimal precision
- Timestamp formats
- Quote currencies
- Instrument naming conventions
Example:
Binance: BTCUSDT
Kraken: XBT/USD
Coinbase: BTC-USD
If you integrate exchanges directly, you must:
- Build symbol mapping tables
- Handle edge cases
- Convert timestamps
- Align precision
- Maintain this forever
This becomes technical debt immediately.
The smarter approach
Use a data provider that already normalizes:
- Exchange identifiers
- Symbol IDs
- Asset codes
- Timestamps (UTC ISO 8601)
- Numeric precision
CoinAPI provides:
- Unified
exchange_idvalues - Canonical symbol identifiers
- ISO 8601 UTC timestamps
- Consistent decimal formatting
- Standardized quote and trade schemas
That means you don’t have to build a symbol mapping layer.
You can:
- Subscribe to BTC/USDT across multiple exchanges
- Receive data in a consistent structure
- Store it immediately
- Compute spreads safely
No manual normalization required.
Common mistakes when building price comparison sites
1. Mixing spot and derivatives prices
Perpetual futures ≠ spot price.
Always compare the same instrument type.
2. Ignoring liquidity
A price difference on a thin book is not actionable.
3. Not handling outages
Exchanges disconnect.
Your system must detect stale feeds.
4. Assuming timestamps are aligned
Two exchanges showing “current” price may differ by 500ms–2s.
Without timestamp alignment, your spreads are misleading.
5. Overloading with polling
5 exchanges × 1 second × multiple symbols = rate limit disaster.
Scaling beyond 5 exchanges
If your goal evolves to:
- 20 exchanges
- 100 symbols
- Historical comparison
- Arbitrage alerts
You now need:
- Centralized market data aggregation
- Normalized schema
- Historical storage
- Real-time streaming infrastructure
At that point, DIY exchange integrations become expensive.
Each new exchange adds:
- New schema
- New edge cases
- New failure modes
How to source exchange data the right way
To build a stable price-difference website, you need:
- Real-time quotes or trades
- Multiple exchange coverage
- Standardized exchange identifiers
- Normalized symbols
- Reliable WebSocket feeds
Instead of integrating 5+ exchange APIs manually, you can use a unified market data API that provides:
- WebSocket streaming for real-time updates
- REST for fallback and historical queries
- Consistent schema across exchanges
- Broad exchange coverage
That removes the integration layer so you can focus on:
- Spread logic
- Arbitrage visualization
- Alerting
- UX
Not exchange maintenance.
Minimal architecture diagram (conceptually)
Data layer
→ WebSocket feeds (5+ exchanges)
→ Normalization layer
→ In-memory cache
Logic layer
→ Spread calculation
→ Staleness detection
→ Alert engine
Delivery layer
→ Backend emits 1-second snapshots
→ Frontend renders updated table
Simple. But only if your data layer is clean.
Final thought: price difference is easy. Correct price difference is infrastructure.
Showing five numbers on a screen is easy.
Showing five synchronized, normalized, executable prices per second - across multiple exchanges - is market data engineering.
If you’re serious about building:
- An arbitrage dashboard
- A cross-exchange analytics platform
- A trading comparison website
- A monitoring or alerting system
Then don’t start with frontend code.
Start with your data layer.
Because if your inputs are:
- Inconsistent
- Unsynchronized
- Stale
- Poorly normalized
Your spreads will look real, but they won’t be tradable.
And in cross-exchange trading, false spreads are worse than no spreads.
So here’s the practical move:
- Use standardized, multi-exchange real-time data
- Ensure symbols and timestamps are already normalized
- Verify you’re comparing executable prices (bid/ask, not just last trade)
- Build your spread engine on top of that
If you want to build this properly, explore the WebSocket market data streams and exchange coverage in the CoinAPI docs, test 5+ exchanges in parallel, and see how clean, normalized feeds change your architecture immediately.
Because in cross-exchange trading, the spread is the product.
And your data layer decides whether that product is real, or fiction.
