"Just polling the CoinGecko API once a minute" — this approach works exactly until the first rate limit. We've encountered projects that needed data faster than every 60 seconds, with minimal latency. A cryptocurrency monitoring system is a pipeline of five layers: data source → normalization → storage → delivery to clients → alerts. Each layer demands its own architecture: WebSocket for low latency, PostgreSQL for storage, Redis for caching, and a message queue for async processing. Over the past 5 years, we've implemented more than 20 such systems for trading platforms and DeFi projects. We guarantee 99.9% uptime and up to 40% reduction in infrastructure costs. To give an example: a client needed real-time prices from three CEXs and two DEXs simultaneously — the system processes 200,000 ticks per second with latency under 100 ms. With 5 years of market presence and 20+ completed projects, we bring deep expertise.
How to Choose Data Sources – Building a Real-Time System
CEX via WebSocket (Lowest Latency)
For real-time crypto prices, connect directly to exchange WebSocket streams. No aggregation, minimal latency:
const ws = new WebSocket('wss://stream.binance.com:9443/stream?streams=btcusdt@ticker/ethusdt@ticker') ws.on('message', (data) => { const { stream, data: tick } = JSON.parse(data) const price = parseFloat(tick.c) const volume24h = parseFloat(tick.v) normalizeAndStore({ source: 'binance', symbol: tick.s, price, volume24h }) }) Similar WebSocket crypto price streams exist for Coinbase, OKX, Bybit. For liquid pairs we use at least three sources and median price to guard against outliers.
DEX On-Chain Prices
For DeFi apps, prices often need to be on-chain. Two approaches:
Uniswap V3 TWAP – resistant to flash loan attacks, requires price over the last N blocks. Chainlink oracle integration is the standard for production smart contracts, using a decentralized oracle network (Chainlink Data Feeds documentation):
AggregatorV3Interface priceFeed = AggregatorV3Interface(0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419); (, int256 price, , uint256 updatedAt,) = priceFeed.latestRoundData(); require(block.timestamp - updatedAt < 3600, "Price feed stale"); Aggregators (CoinGecko/CoinMarketCap)
For historical data and less liquid tokens. Rate limits: CoinGecko free tier – 30 requests/min. We cache aggressively.
| Source | Latency | Reliability | Use Case |
|---|---|---|---|
| CEX WebSocket (Binance) | <100 ms | High | Real-time trading |
| DEX TWAP (Uniswap V3) | ~12 s (block) | Medium | DeFi apps |
| Chainlink Price Feeds | ~1 min | Very high | Production smart contracts |
| CoinGecko API | 1–60 s | Medium | Historical data |
Why TimescaleDB?
Price ticks are a typical time-series use case. PostgreSQL with the TimescaleDB extension is a solid choice if you already use PG. TimescaleDB for tick storage enables automatic partitioning and compression, saving up to 60% disk space:
CREATE TABLE price_ticks ( time TIMESTAMPTZ NOT NULL, symbol VARCHAR(20) NOT NULL, source VARCHAR(20) NOT NULL, price NUMERIC(20, 8) NOT NULL, volume_24h NUMERIC(30, 2) ); SELECT create_hypertable('price_ticks', 'time'); -- Automatic aggregation into OHLCV candles SELECT time_bucket('1 minute', time) AS bucket, symbol, first(price, time) AS open, max(price) AS high, min(price) AS low, last(price, time) AS close, sum(volume_24h) AS volume FROM price_ticks WHERE time > NOW() - INTERVAL '1 hour' GROUP BY bucket, symbol ORDER BY bucket DESC; TimescaleDB automatically partitions data by time. Retention policy – auto-delete ticks older than 30 days, keep only aggregates for history. We use compression to save up to 60% disk space.
How Alerts Work
Price Change Alert
Price changed by X% over Y minutes:
class PriceAlertService { constructor(redis) { this.redis = redis } async checkAlert(symbol, currentPrice) { const pastPrice = await this.redis.get(`price:${symbol}:1m_ago`) if (pastPrice) { const changePercent = Math.abs((currentPrice - pastPrice) / pastPrice * 100) if (changePercent >= ALERT_THRESHOLD_PERCENT) { await this.triggerAlert({ symbol, currentPrice, changePercent }) } } await this.redis.setex(`price:${symbol}:1m_ago`, 60, currentPrice.toString()) } } Stale Data Alert
If a source stops updating, we check the last tick's timestamp and send a notification to Telegram/Slack/email. Configurable webhooks allow integration with any system.
| Metric | Threshold | Action |
|---|---|---|
| Update delay | >5 seconds | WebSocket reconnect |
| No data from source | >30 seconds | Failover to backup |
| Price change over 1 minute | >1% | Price change alert |
TWAP for Manipulation Protection
TWAP (Time-Weighted Average Price) – average price over a defined period. In Uniswap V3 it's calculated over the last block and is resistant to short-term manipulation like flash loan attacks. For DeFi apps, this is the security standard.
Process
- Analysis – define requirements: sources, latency, data volume, alert types.
- Design – pipeline architecture, DB choice, data schema, delivery protocol.
- Implementation – connect sources, write collector, normalization, alerts, and API.
- Testing – load testing (up to 100,000 ticks/s), failover verification, unit tests.
- Deployment – deploy on client infrastructure, set up monitoring.
What's Included
- Architectural documentation with pipeline and data schema.
- Access to the repository with collector, alerts, and API source code.
- Integration with your infrastructure (CI/CD, monitoring, logging).
- Training session for your team (up to 2 hours).
- Support for 30 days after deployment.
Timelines and Cost
Timelines range from 2 to 8 weeks depending on complexity. Average project budget is between $5,000 and $20,000. We guarantee up to 40% reduction in infrastructure costs – clients typically save $2,000-$8,000 per month. We'll evaluate your project for free.
Common Mistakes and How to Avoid Them
| Mistake | Solution |
|---|---|
| Missing reconnect with exponential backoff for WebSocket | Implement automatic reconnect with incremental delay |
| Storing all ticks without aggregation | Use TimescaleDB with compression and retention policies |
| Using a single source | Connect at least two independent sources with failover |
| Checking data freshness only client-side | Set up stale data alerts server-side |
| Ignoring aggregator rate limits | Cache responses and limit request frequency |
Get a consultation from an engineer with over 5 years of experience in building cryptocurrency monitoring systems. Contact us to evaluate your project.







