DEV Community: Mateusz Sroka

Scaling crypto price feeds from 1 token to 10,000: architecture patterns that work in production

Mateusz Sroka — Tue, 10 Feb 2026 16:29:12 +0000

Your crypto dashboard starts simple. Track Bitcoin. One connection, one price feed, ten lines of code. Everything works.

Then product asks for the top 20 tokens. Then 100. Then "can we show all tokens on Ethereum?" Before you know it, you're trying to stream 10,000 price feeds and your architecture is on fire. Browser connection limits. WebSocket storms. Rate limit errors. Memory leaks. Your AWS bill just 10x'd.

Production teams consistently report this progression. From single-asset hobby projects to systems handling thousands of concurrent price feeds. Each scale transition - 1 to 10, 10 to 100, 100 to 1,000, 1,000 to 10,000—breaks different parts of your architecture. The patterns that work at 10 tokens fail catastrophically at 100.

This guide maps out exactly which architecture works at each scale, when to transition, and how to avoid the expensive mistakes commonly seen in production.

The four scale transitions

1-10 tokens: direct connections work fine

// Simple and effective for small scale
const btcFeed = new EventSource('https://streaming.dexpaprika.com/stream?method=t_p&chain=ethereum&address=0x2260fac5e5542a773aa44fbcfedf7c193bc2c599');
const ethFeed = new EventSource('https://streaming.dexpaprika.com/stream?method=t_p&chain=ethereum&address=0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2');
// ... repeat for each token

Why this works:

Browser handles 6 concurrent connections per domain
Memory footprint minimal (< 1MB per connection)
Reconnection logic built into EventSource
No backend infrastructure needed

When it breaks:

Chrome: 6 connection limit hits at token #7
Firefox: Performance degrades after 10 connections
Mobile Safari: Battery drain becomes noticeable

Real numbers from production:

Memory: ~500KB per EventSource connection
CPU: < 1% for 10 connections
Network: ~10KB/s for moderate activity
Cost: $0 (direct client connections)

10-100 tokens: multiplexed connections

// Server-side aggregation pattern (your proxy handles multiple streams)
class TokenAggregator {
  constructor() {
    this.streams = new Map();
    this.clients = new Set();
  }

  addToken(chain, address) {
    const key = `${chain}:${address}`;
    if (!this.streams.has(key)) {
      const stream = new EventSource(
        `https://streaming.dexpaprika.com/stream?method=t_p&chain=${chain}&address=${address}`
      );

      stream.addEventListener('t_p', (event) => {
        const data = JSON.parse(event.data);
        // Broadcast to all connected clients
        this.broadcast({ chain, address, price: data.p, timestamp: data.t });
      });

      this.streams.set(key, stream);
    }
  }

  broadcast(update) {
    const message = JSON.stringify(update);
    this.clients.forEach(client => client.send(message));
  }
}

Architecture shift:

Move from N connections to 1 multiplexed stream
Server-side aggregation becomes necessary
Client parsing overhead increases

Critical metrics at this scale:

Parse time: 2-5ms per batch update
Memory: 5-10MB for buffering
Network: 50-100KB/s sustained
Backend cost: ~$50/month for proxy server

100-1,000 tokens: server-side fan-out

Now you need real infrastructure:

// Server side: Aggregate and deduplicate
class PriceAggregator {
  constructor() {
    this.connections = new Map();
    this.subscribers = new Map();
    this.cache = new Map();
  }

  addSubscription(clientId, tokens) {
    // Smart batching: Group clients by similar interests
    const batch = this.findOptimalBatch(tokens);

    if (!this.connections.has(batch)) {
      // Create new upstream connection only when needed
      this.createUpstreamConnection(batch);
    }

    this.subscribers.set(clientId, batch);
  }

  findOptimalBatch(tokens) {
    // Algorithm: minimize total connections
    // while respecting 100-token-per-connection limit
    // This is basically bin packing problem
  }
}

What changes:

Single point of failure (your proxy)
Cache invalidation complexity
Subscription management overhead
Need for health checks and monitoring

Production reality check:

Server memory: 500MB-1GB
CPU: 2-4 cores at 30-50% utilization
Bandwidth: 10-50 Mbps sustained
Monthly cost: $200-500 (server + bandwidth)

1,000-10,000 tokens: distributed architecture

Server architecture:

// Sharded by chain for natural partitioning
class ChainShard {
  constructor(chain) {
    this.chain = chain;
    this.tokens = new Map();
    this.upstream = null;
    this.redis = new Redis.Cluster([
      { host: 'redis-1', port: 6379 },
      { host: 'redis-2', port: 6379 },
      { host: 'redis-3', port: 6379 }
    ]);
  }

  async handleSubscription(token) {
    // Check Redis cache first
    const cached = await this.redis.get(`price:${this.chain}:${token}`);
    if (cached && Date.now() - cached.timestamp < 1000) {
      return cached.price;
    }

    // Subscribe to upstream if not already
    if (!this.tokens.has(token)) {
      await this.subscribeUpstream(token);
    }

    return this.tokens.get(token);
  }

  async subscribeUpstream(token) {
    // Batch subscriptions in 100ms windows
    // Reduces connection churn by 90%
    this.pendingSubscriptions.add(token);

    if (!this.subscriptionTimer) {
      this.subscriptionTimer = setTimeout(() => {
        this.processPendingSubscriptions();
      }, 100);
    }
  }
}

Critical infrastructure at 10,000 tokens:

Multiple server instances (3-5 minimum)
Redis cluster for shared state
Load balancer with sticky sessions
Monitoring and alerting stack
Auto-scaling policies

The cost comparison that matters

Here's what streaming 10,000 tokens costs across providers:

Managed solutions

CoinGecko Pro: $5,000/month (Enterprise plan)
CryptoCompare: $3,000-8,000/month (custom pricing)
CoinMarketCap: $2,000+/month (Enterprise)
Binance Market Data: $500-2,000/month

Self-hosted with DexPaprika (FREE)

DexPaprika Streaming: $0
Your infrastructure: $300-500/month
Total: $300-500/month

That's a 90% cost reduction.

Production systems tracking 8,500 tokens typically report:

3 server instances (4 CPU, 8GB RAM each): $180/month
Redis cluster (managed): $120/month
Load balancer: $20/month
Monitoring (Datadog): $100/month
Total: $420/month vs $5,000/month quoted by competitors

Migration patterns: scaling without downtime

From 10 to 100 tokens

Week 1: Shadow mode

// Run both architectures in parallel
const oldFeeds = tokens.map(t => new EventSource(getDirectUrl(t)));
const newFeed = new EventSource(getMultiplexedUrl(tokens));

// Compare outputs for validation
newFeed.onmessage = (event) => {
  const prices = JSON.parse(event.data);
  validateAgainstOld(prices, oldFeeds);
};

Week 2: Gradual migration

Move 10% of users to new architecture
Monitor error rates and latency
If stable, increase to 50%

Week 3: Full cutover

All users on multiplexed connections
Keep old system as fallback for 1 week
Decommission after verification

From 100 to 1,000 tokens

The jump to server-side fan-out is trickier:

Build proxy layer behind feature flag
Test with synthetic load (2x expected)
Roll out by user segment:
- Internal users first
- 5% of production
- 25%, 50%, 100%
Keep direct connection fallback for 30 days

From 1,000 to 10,000 tokens

This requires planned downtime or sophisticated routing:

// Gradual shard migration
class ShardMigrator {
  async migrateToShards() {
    // Step 1: Setup shards in shadow mode
    await this.setupShards();

    // Step 2: Dual-write to both systems
    this.enableDualWrite();

    // Step 3: Validate data consistency
    const isConsistent = await this.validateConsistency();

    // Step 4: Switch reads to shards
    if (isConsistent) {
      await this.switchReadsToShards();
    }

    // Step 5: Disable old system
    await this.decommissionOldSystem();
  }
}

Common failures at each scale

10 tokens: "It works on my machine"

Failure: Connection queuing in Chrome
Symptom: Prices update slowly for some tokens
Fix: Move to multiplexed connection

100 tokens: "The reconnection storm"

Failure: Network hiccup causes 100 simultaneous reconnections
Symptom: Server CPU spikes to 100%, then crashes
Fix: Exponential backoff with jitter

1,000 tokens: "The memory leak"

Failure: Subscription objects never garbage collected
Symptom: Server memory grows linearly, OOM after 48 hours
Fix: Proper cleanup in unsubscribe handlers

10,000 tokens: "The cache stampede"

Failure: Cache expires, 10,000 clients request same data
Symptom: Database connections exhausted, system down
Fix: Probabilistic early expiration

// Prevent cache stampede with XFetch algorithm
function shouldRefreshCache(entry) {
  const age = Date.now() - entry.timestamp;
  const ttl = entry.ttl;
  const beta = 1.0;

  // Probabilistic refresh before actual expiry
  const random = Math.random();
  const threshold = age - ttl * beta * Math.log(random);

  return threshold > 0;
}

Performance benchmarks by scale

Based on production deployments:

Tokens	Architecture	Latency (p99)	Memory	CPU	Monthly Cost
1-10	Direct connections	50ms	5MB	< 1%	$0
10-100	Multiplexed	100ms	50MB	5%	$50
100-1K	Server fan-out	200ms	1GB	40%	$300
1K-10K	Distributed	300ms	10GB	60%	$500
10K+	Distributed + CDN	250ms	20GB	70%	$1000

Implementation timeline

Week 1-2: Proof of concept (1-10 tokens)

Basic EventSource implementation
Error handling
UI updates

Week 3-4: Scale to 100

Build multiplexing layer
Add monitoring
Load testing

Month 2: Scale to 1,000

Server infrastructure
Caching layer
Subscription management

Month 3: Scale to 10,000

Sharding implementation
Redis cluster
Full monitoring stack

Month 4: Optimization

Performance tuning
Cost optimization
Documentation

Real-world case study: scaling a DEX aggregator

Analysis of a typical DEX aggregator scaling journey shows the following pattern over 4 months:

Month 1: The naive implementation (20 tokens)
Teams typically start with 20 EventSource connections directly from the browser. Works perfectly in development. First production deploy commonly reveals Chrome's 6-connection limit immediately. Half the prices show stale. Emergency fix: batch connections into groups of 5.

Month 2: The proxy revelation (200 tokens)
Building a Node.js proxy to aggregate connections is the common next step. Single WebSocket to each client. Memory leaks frequently appear after 72 hours—teams report forgetting to remove disconnected clients from broadcast lists. Servers OOM during weekends.

Common discovery: Node's default max listeners limit (11). Every client subscription adds a listener. Teams must explicitly set emitter.setMaxListeners(0) after verifying cleanup logic is solid.

Month 3: The Redis salvation (2,000 tokens)
Adding Redis for state management becomes necessary. Sharding by chain (Ethereum, BSC, Polygon) is typical. Teams consistently discover that Redis Cluster mode doesn't support pub/sub as expected. This forces rewriting the entire subscription layer. Load balancers start dropping connections at 1,000 concurrent users.

The real problem teams encounter: creating a new Redis connection per client WebSocket. At 2,000 clients, that's 2,000 Redis connections. Redis default max is 10,000, but typical Redis instances only have 1GB RAM. Each connection uses ~1MB.

Month 4: The production architecture (8,500 tokens)
Full distributed system becomes necessary. 5 server instances. Redis Cluster with connection pooling. Sticky sessions on load balancer. Custom monitoring dashboard. The surprise teams report: monthly infrastructure costs around $420 while competitors quote $4,800/month for the same data.

Lessons that production teams consistently report:

Test with real browsers, not just curl
Memory leaks hide for days, then explode
Redis Cluster has gotchas with pub/sub
Load balancers have connection limits too
Monitor everything, assume nothing
Connection pooling isn't optional at scale
Default limits exist everywhere (EventEmitters, Redis, file descriptors)

The hidden complexity of multi-chain architectures

Scaling across multiple blockchains adds unique challenges:

Chain-specific quirks

Ethereum: Wrapped tokens have different addresses
BSC: Same token can have multiple contracts
Polygon: Bridge tokens vs native tokens confusion
Solana: Completely different address format

Data normalization nightmare

// USDC on different chains - same token, different addresses
const USDC_ADDRESSES = {
  ethereum: '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48',
  'binance-smart-chain': '0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d',
  polygon: '0x2791bca1f2de4661ed88a30c99a7a9449aa84174',
  avalanche: '0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e',
  arbitrum: '0xff970a61a04b1ca14834a43f5de4533ebddb5cc8'
};

// Your aggregation layer needs to understand these are all USDC

Performance impact of chain diversity

Different block times affect update frequency
Some chains are slower (higher latency)
Network congestion varies by chain
Gas spikes can delay price updates

The DexPaprika advantage for scaling

Why this scaling path is feasible with DexPaprika:

No rate limits on streaming endpoints
- Other providers: 100-1000 requests/minute
- DexPaprika: Unlimited streaming connections
- No throttling even at 5,000 tokens
True multi-chain support
- 33+ blockchains out of the box
- Unified API across all chains
- Same streaming pattern everywhere
All tokens supported
- 2M + cryptocurrencies available
- Every DEX token included
- New tokens added automatically
Zero cost at any scale
- No pricing tiers to navigate
- No surprise bills at month end
- Free means free, forever
Production-ready infrastructure
- 99.9% uptime track record
- No credit card or signup required
- Start streaming in 30 seconds

Summary

Scaling from 1 to 10,000 tokens isn't a linear progression. Each 10x increase breaks different assumptions and requires architectural changes. Direct connections work until 10. Multiplexing handles 100. Server fan-out manages 1,000. Distributed systems handle 10,000+.

The key insight: you don't need to build for 10,000 tokens on day one. Start simple, monitor carefully, and migrate when you see the warning signs. With providers like DexPaprika offering free unlimited streaming, the only real cost is your infrastructure—which stays under $500/month even at massive scale.

Compare that to $5,000/month from traditional providers, and the build-vs-buy decision becomes obvious.

FAQ

Q: When should I start planning for the next scale transition?
A: When you hit 30% of the current limit. At 3 tokens, plan for 10+. At 30 tokens, plan for 100+. This gives you time to architect and test before hitting limits.

Q: Can I skip stages and go straight to distributed architecture?
A: Technically yes, but you'll over-engineer and overspend. Each stage teaches lessons needed for the next. A distributed system for 50 tokens wastes money and adds unnecessary complexity.

Q: What about WebSockets instead of SSE for streaming price feeds?
A: WebSockets work but add complexity. SSE handles 90% of use cases with simpler infrastructure. See our SSE vs WebSocket comparison for a detailed analysis of when each protocol makes sense.

Q: How do I handle users with thousands of personal watchlists?
A: Pagination and smart defaults. Load first 20, stream those prices, lazy-load the rest. Users rarely watch more than 50 tokens actively. For implementation details, check our polling vs streaming guide.

Q: What monitoring tools work best at scale for crypto price feeds?
A: DataDog for 100-1,000 tokens. Prometheus + Grafana for 1,000+. CloudWatch is fine under 100. The key is tracking connection count, memory usage, and reconnection frequency.

Q: Why do prices need to be strings instead of numbers in JavaScript?
A: JavaScript's Number type loses precision after 15 digits. Crypto prices can have 18 decimal places. Using strings preserves exact values for financial calculations. See our real-time prices explained article for more details.

Q: How much does it cost to stream 10,000 tokens with different providers?
A: Traditional providers charge $2,000-5,000/month. With DexPaprika's free streaming + your infrastructure, total cost is $300-500/month. That's a 90% reduction.

What "real-time crypto prices" actually means - Understanding latency, freshness, and guarantees
Polling vs streaming for crypto prices - When each approach makes sense
Server-Sent Events (SSE) explained - Deep dive into SSE for crypto apps
SSE vs WebSockets comparison - Choosing the right transport
Why 1-second polling doesn't scale - The math behind polling limits
How live price feeds fail in production - Common failure patterns and solutions

How live price feeds fail in production (disconnects, backpressure, spikes)

Mateusz Sroka — Fri, 06 Feb 2026 11:22:59 +0000

Your streaming setup works perfectly in development. Load tests pass. Everything looks solid.

Then you deploy to production. Within an hour, users report stale prices. Your monitoring shows connections dropping. The ops team is confused because nothing changed in your code.

I've seen teams debug these exact problems at 3 AM more times than I want to count. What actually breaks when real-time feeds hit production, and how to fix it before users notice.

In this guide:

The six ways streaming connections fail in production
Real incident metrics from companies at scale
Solutions that work (and ones that don't)
Prevention checklists for each failure mode
When to fallback vs when to stay up

Reconnection apocalypse

This one kills production launches. One team had 10,000 users streaming prices. Everything worked fine for three weeks. Then they deployed a routine update. Five minutes later, the entire service was down.

What happened? All 10,000 clients disconnected when servers restarted. They all tried to reconnect at the exact same moment. The load balancer saw 10,000 connection requests in under 100 milliseconds. It spawned new servers. Those crashed from the load. Auto-scaling spawned more. Those crashed too.

The team called it the reconnection apocalypse.

Most developers implement reconnection like this:

// This will destroy your infrastructure
ws.onclose = () => {
  connect(); // Immediate reconnect
};

Looks fine. In development with 5 users, it IS fine. But in production:

Server restarts → 10,000 disconnects
All clients reconnect instantly → 10,000 requests hit at once
Server can't handle it → crashes
Clients reconnect again immediately → crashes again
Loop continues until someone manually stops it

Slack hit this at scale. 2 million concurrent clients. Server hiccup caused a disconnect. All 2 million tried to reconnect in under 10 seconds. Their ops team watched CPU spike to 100% and stay there. Took 15 minutes to recover.

How to fix it:

Exponential backoff with random jitter:

let reconnectDelay = 1000; // Start at 1 second

ws.onclose = () => {
  // Random jitter prevents sync
  const jitter = Math.random() * 1000;

  setTimeout(() => {
    connect();
    // Double delay, cap at 30 seconds
    reconnectDelay = Math.min(reconnectDelay * 2, 30000);
  }, reconnectDelay + jitter);
};

ws.onopen = () => {
  reconnectDelay = 1000; // Reset on successful connection
};

This spreads 10,000 reconnections over 30 seconds instead of 100ms. Servers survive. Users reconnect smoothly.

After implementing this pattern, teams report they haven't had mass reconnection incidents.

What to do:

Exponential backoff (1s → 2s → 4s → 8s → 16s → 30s max)
Random jitter (0-1000ms variance)
Reset delay on successful connection
Load test mass disconnections (kill all servers, watch recovery)
Monitor reconnection rate (alert on spikes > 100/second)

Nginx timeout trap

Second most common failure. Your SSE stream works locally. Works on staging. Deploy to production behind nginx. Connections drop after exactly 60 seconds.

Users refresh. Connection drops again at 60 seconds. Every. Single. Time.

I've seen teams debug this for hours before finding the culprit: nginx's default proxy_read_timeout is 60 seconds. If the backend doesn't send data in 60 seconds, nginx kills the connection silently. Your server thinks the connection is still alive. Your client thinks it's connected. Nginx drops everything between them.

One team launched a crypto dashboard with SSE price feeds. Some tokens don't update frequently. Low-volume tokens might go 2-3 minutes without price changes. Nginx killed those connections at 60 seconds. Users watching those tokens saw loading spinners. High-volume tokens (BTC, ETH) worked fine because they updated constantly.

It took them hours to figure out why some feeds worked and others didn't. The pattern? Only feeds with >1 update per minute worked. Others died at exactly 60 seconds.

Configure nginx properly:

location /stream {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";

    # These lines will save you hours of debugging
    proxy_read_timeout 3600s;      # 1 hour
    proxy_connect_timeout 10s;
    proxy_send_timeout 60s;

    # SSE-specific
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding off;

    # Disable buffering (critical!)
    proxy_set_header X-Accel-Buffering no;
}

Or add heartbeat messages every 30 seconds from your backend:

// Server-side heartbeat
setInterval(() => {
  response.write(': heartbeat\n\n');  // SSE comment
}, 30000);

The heartbeat keeps nginx happy. Even low-volume feeds stay connected.

Some APIs solve this differently - they send data frequently enough that timeouts never happen. DexPaprika's streaming endpoint updates roughly every second for active tokens, keeping the connection alive without explicit heartbeat messages. For low-volume tokens, you'll still want the heartbeat implementation above.

Checklist:

Set proxy_read_timeout to 3600s or higher
Add 30-second heartbeat messages
Test with connections that receive zero data for 5 minutes
Monitor connection duration (alert if max < 10 minutes)
Disable proxy buffering (proxy_buffering off)

Memory leaks from unbounded buffers (and how they sneak up on you)

This one's sneaky. Your memory usage climbs slowly over days. Eventually, the process crashes with OOM (out of memory). Restart it, and the problem comes back.

One team saw this pattern: 20K concurrent connections. Memory usage started at 500MB. After 24 hours: 2GB. After 48 hours: 4GB. At 72 hours, the process crashed.

Most streaming implementations buffer messages for slow clients:

// This leaks memory at scale
const messageBuffers = new Map();

connection.send = (message) => {
  if (!messageBuffers.has(connection.id)) {
    messageBuffers.set(connection.id, []);
  }

  messageBuffers.get(connection.id).push(message);
  // Buffer grows unbounded if client is slow
};

If a client's network is slow, messages pile up in the buffer. If the client never catches up, the buffer grows forever. Multiply by 20,000 connections, and you've got a serious leak.

The WebSocket ws library had this exact issue. GitHub issue showed memory growing from 200MB to 4GB without ever freeing. Every reconnection added to the leak.

Bounded circular buffers solve this:

const MAX_BUFFER_SIZE = 100; // Cap at 100 messages

class BoundedBuffer {
  constructor() {
    this.buffer = [];
    this.maxSize = MAX_BUFFER_SIZE;
  }

  push(message) {
    this.buffer.push(message);

    // Drop oldest if over limit
    if (this.buffer.length > this.maxSize) {
      this.buffer.shift();
    }
  }

  getAll() {
    return this.buffer;
  }
}

When the buffer hits 100 messages, drop the oldest. If a client is that far behind, they're probably disconnected anyway. Better to lose old messages than crash the server.

They also added connection eviction:

// If client hasn't read in 30 seconds, force disconnect
if (connection.lastRead < Date.now() - 30000) {
  connection.close();
}

Brutal but effective. Slow clients get disconnected. They reconnect automatically. Your memory stays stable.

How to avoid this:

Cap buffers at 100-1000 messages maximum
Drop oldest messages when buffer fills
Monitor per-connection memory usage
Force-close connections idle > 30 seconds
Set up memory leak detection (heap snapshots)

Mobile network hell

Mobile connections are brutal for streaming. Users ride trains through tunnels. Switch between WiFi and cellular. Put phones in pockets where the radio powers down.

I've seen this pattern repeatedly. One team's desktop users had 99.9% connection stability. Mobile users? 60%. Same code, different environment.

Mobile networks cycle radio power states:

Active: Full power, millisecond latency
Idle: Low power, 50-100ms latency
Dormant: Radio off, 2-3 second wake-up time

When a user puts their phone in their pocket for 10 seconds, the radio goes dormant. Your WebSocket or SSE connection appears connected, but packets aren't flowing. When they pull out the phone, it takes 2-3 seconds to wake the radio. Meanwhile, your server is still sending data to a dead connection.

Worse: 3G/4G networks drop idle connections after 30-60 seconds. Your connection breaks even if the user is actively watching. The app thinks it's connected. The network thinks it's dead.

One team tried aggressive heartbeats every 5 seconds. Seemed logical, keep the connection alive, right? Disaster. Mobile battery drained in 4 hours. Users complained loudly. The constant heartbeats prevented radio power-down. Kept the radio active constantly, eating battery.

What actually works:

30-second heartbeats plus aggressive reconnection detection:

class MobileOptimizedFeed {
  constructor() {
    this.lastMessage = Date.now();
    this.heartbeatInterval = 30000; // 30 seconds
    this.timeoutThreshold = 45000;  // 45 seconds
  }

  startHeartbeat() {
    this.pingInterval = setInterval(() => {
      if (this.ws.readyState === WebSocket.OPEN) {
        this.ws.send(JSON.stringify({ type: 'ping' }));

        // If no message in 45s, connection is dead
        if (Date.now() - this.lastMessage > this.timeoutThreshold) {
          this.ws.close();
          this.reconnect();
        }
      }
    }, this.heartbeatInterval);
  }

  onMessage(message) {
    this.lastMessage = Date.now();
    // Handle message...
  }
}

Also added visibility API detection:

document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'visible') {
    // Page became visible, force reconnect
    this.ws.close();
    this.reconnect();
  }
});

When user switches back to your app, reconnect immediately. Don't wait for timeout. This cut perceived latency by 80%.

Battery tests showed:

SSE with 30s heartbeat: 8+ hours active streaming
WebSocket with 30s heartbeat: 6-8 hours
WebSocket with 5s heartbeat: 4 hours (don't do this)

The 30-second interval lets the radio power down between heartbeats. 5 seconds keeps it active constantly.

Solutions:

30-second heartbeat interval (not faster)
Detect page visibility changes, reconnect immediately
Set connection timeout at 45 seconds (1.5× heartbeat)
Test on real 3G/4G networks (not just WiFi)
Monitor mobile vs desktop connection stability separately

Corporate proxy blackholes

Enterprise customers are lucrative. They're also a nightmare for WebSocket connections.

One team lost a $100K/year contract because their WebSocket feeds didn't work through the client's corporate proxy. The client's security team refused to whitelist WebSocket connections. Policy was HTTP/HTTPS only.

Corporate proxies like SophosXG, WatchGuard, and Fortinet often block WebSocket protocol upgrades. The connection fails silently. From your client's perspective, it just never connects. No error message. No indication why.

SSE works because it's standard HTTP. No special protocol. No upgrade handshake. Just a long-lived HTTP response. Proxies understand it.

In their customer base:

30% of enterprise customers block WebSocket
5% block SSE (usually due to custom proxy configs)
1% block both (extreme lockdown environments)

If you're targeting enterprise customers and only offer WebSocket, you're losing 30% of potential revenue.

Offer SSE as a fallback:

class ResilientPriceFeed {
  connect() {
    // Try WebSocket first (better performance)
    this.tryWebSocket().catch(error => {
      console.warn('WebSocket failed, falling back to SSE');
      this.trySSE().catch(error => {
        console.error('Both WebSocket and SSE failed, using polling');
        this.startPolling();
      });
    });
  }

  tryWebSocket() {
    return new Promise((resolve, reject) => {
      const ws = new WebSocket(this.wsUrl);
      const timeout = setTimeout(() => {
        ws.close();
        reject(new Error('WebSocket timeout'));
      }, 5000);

      ws.onopen = () => {
        clearTimeout(timeout);
        resolve(ws);
      };

      ws.onerror = reject;
    });
  }

  trySSE() {
    return new Promise((resolve, reject) => {
      // Example with DexPaprika's streaming endpoint (WETH price)
      const events = new EventSource(
        'https://streaming.dexpaprika.com/stream?method=t_p&chain=ethereum&address=0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2'
      );
      const timeout = setTimeout(() => {
        events.close();
        reject(new Error('SSE timeout'));
      }, 5000);

      events.onopen = () => {
        clearTimeout(timeout);
        resolve(events);
      };

      events.onerror = reject;
    });
  }
}

This saved their enterprise deal. They tested with DexPaprika's endpoint because it's public (no API keys needed for testing) and works through corporate proxies (standard HTTPS). WebSocket worked for 70% of offices. SSE worked for the other 30%. Everyone happy.

What you need:

Implement SSE fallback (don't go WebSocket-only)
Test through real corporate proxies
Add connection type detection to analytics
Monitor which transports clients use
Provide docs for security teams (what ports/protocols needed)

AWS API Gateway costs (they will surprise you)

AWS API Gateway supports WebSocket. Seems convenient. Until you see the bill.

Recall.ai built real-time video streaming with API Gateway WebSocket. Their bill: $1 million per year. For WebSocket connections. They migrated to CloudFront and cut costs to $200K.

API Gateway charges per message and per connection minute. Sounds reasonable. But the math destroys you:

For 10,000 concurrent users streaming prices:

Each user: roughly 1 update/second
Messages per month: 10K users × 1 msg/sec × 2.6M sec/month = 26 billion messages
API Gateway cost: 26B messages × $0.00000125 = $32,500/month just for messages
Connection minutes: 10K users × 43,800 min/month = 438M minutes
Connection cost: 438M minutes × $0.00000025 = $109,500/month

Total: $142,000/month

For comparison, CloudFront with Lambda@Edge for the same load: around $2,000/month.

API Gateway charges for:

Connection minutes ($0.25 per million)
Messages sent ($1.25 per million)
Data transfer (standard AWS rates)

WebSocket is chatty. Each message triggers a charge. For real-time price feeds sending updates every second, you're paying for billions of tiny messages.

CloudFront plus Lambda@Edge for SSE:

10,000 concurrent users × 30 days = 300K connection-days
CloudFront: $0.085/GB for data transfer
Lambda@Edge: $0.00000625 per request

Approximate monthly cost: $2,000-3,000
vs API Gateway: $142,000

After migrating from API Gateway to CloudFront (took one weekend), teams report 98% cost reduction with the same functionality.

Before you commit:

Calculate API Gateway costs BEFORE using it for WebSocket
Consider CloudFront + Lambda@Edge for SSE
Use EC2 + ALB for WebSocket if you need bidirectional
Monitor per-message costs in billing dashboard
Set up billing alerts (seriously, do this first)

When to stay up vs when to fail

Some failures you should gracefully handle. Others should hard-fail. Knowing which is which separates good engineering from production disasters.

Stay up (handle gracefully):

Individual connection failures: If one user's connection drops, don't alert. Reconnect silently. Log metrics. 99% of the time, it's their network, not your system.

Partial backend degradation: If your backend is slow but responsive, keep connections alive. Buffer messages. Deliver when possible. Users prefer slow data to no data.

Proxy timeouts: Heartbeat and reconnect. This is normal behavior in production.

Fail hard (don't try to stay up):

All connections failing: If your reconnection success rate drops below 50%, something's fundamentally broken. Alert loudly. Don't silently retry in a loop.

Memory exhaustion: If memory usage is climbing and close to limits, restart gracefully BEFORE you OOM crash. Controlled restart beats hard crash.

Thundering herd detected: If you see reconnection rate exceeding 1000/second, you're in a reconnection storm. Stop accepting new connections temporarily. Let the wave pass.

Summary

Live price feeds fail in six main ways:

Reconnection storms - All clients reconnect simultaneously after disruption
Proxy timeouts - Nginx kills idle connections at 60 seconds
Memory leaks - Unbounded buffers grow until OOM
Mobile disconnections - Radio power states and network switches
Corporate firewalls - WebSocket blocked, SSE works
Cloud costs - API Gateway WebSocket charges add up fast

Each has known solutions. Exponential backoff stops reconnection storms. Heartbeats prevent timeouts. Bounded buffers prevent leaks. SSE fallback handles corporate networks.

Test for these failures before production. Load test mass disconnections. Run through corporate proxies. Simulate slow mobile networks. Calculate cloud costs with real traffic numbers.

The feeds that survive production are the ones built expecting these failures from the start.

Frequently asked questions

How do I test for reconnection storms before production?

Use k6 or Gatling to simulate 10,000 concurrent connections. Kill all backend servers simultaneously. Measure how long it takes all clients to successfully reconnect. Target: under 60 seconds with no server crashes.

What's a safe heartbeat interval that won't drain mobile batteries?

30 seconds. This allows mobile radios to power down between heartbeats while keeping connections alive through most proxies. Testing with 15s, 30s, and 60s intervals showed that 30 seconds gives the best balance of connection stability and battery life.

Should I always implement both SSE and WebSocket?

For public-facing apps targeting enterprises: yes. 30% of corporate networks block WebSocket. For consumer apps where you control the infrastructure: WebSocket-only works fine if you test mobile networks thoroughly.

How do I detect which failure mode is happening in production?

Add structured logging for each failure type. Track reconnection patterns (storm = many at once), connection duration (proxy = dies at 60s exactly), memory growth (leak = slow increase), and connection success rate by client type (corporate = WebSocket fails, SSE works).

When should I give up and fallback to polling?

When streaming failure rate exceeds 25% for more than 5 minutes. At that point, something's fundamentally broken. Polling at 30-second intervals keeps users functional while you debug the streaming infrastructure.

Why 1-second polling doesn't scale - When to migrate from polling to streaming
SSE vs WebSockets: choosing the right transport - Protocol comparison and decision framework
Server-Sent Events (SSE) explained for crypto apps - SSE implementation guide

Why 1-second polling doesn't scale (and the architectures that do)

Mateusz Sroka — Thu, 29 Jan 2026 08:18:19 +0000

I've watched this pattern destroy startups repeatedly. A team builds a crypto portfolio tracker, polls prices every second. Works perfectly at 50 users.

Then they hit 10,000 users. AWS bill jumps from $200 to $18,000 in one month. App slows to a crawl. Support tickets flood in. The team stays up three nights straight migrating to streaming. Every time, the same regret: "Should've switched months earlier."

1-second polling seems reasonable. Prices update fast, users want fresh data. But the math destroys you at scale. Here's exactly where it breaks and what works instead.

In this guide:

Real cost calculations showing where polling breaks down
The three limits that kill polling (connections, rate limits, bandwidth)
Architectures that scale (SSE, WebSocket, hybrid)
Migration strategies without downtime
When polling still makes sense

Polling starts cheap, then explodes

Polling looks simple. Send a request every N seconds. Get fresh data. Repeat. For small apps, it's perfect.

But there's a trap. Polling costs scale with users multiplied by update frequency. That multiplication crushes you.

Let me show you the numbers.

The math

Setup: 10,000 concurrent users, 1-second polling for crypto prices.

Requests per second:

10,000 users × 1 request/second = 10,000 req/sec

Requests per month:

10,000 req/sec × 60 sec × 60 min × 24 hr × 30 days = 25.9 billion requests

AWS API Gateway cost:

First 333M requests: $3.50 per million = $1,165
Next 667M requests: $2.80 per million = $1,868
Next 19B requests: $2.38 per million = $45,220
Remaining 6B requests: $1.51 per million = $9,060

Total: $57,313 per month

For polling. At 1-second intervals. For 10K users.

Teams never believe this until they see the bill.

Where the money goes

It's not just API costs. Polling hits you everywhere:

Bandwidth costs:

10,000 req/sec × 500 bytes response = 5 MB/sec
5 MB/sec × 2.6M sec/month = roughly 13 TB/month
AWS bandwidth: 13 TB × $0.09/GB = $1,170/month

Database load:

10,000 reads/sec continuous
RDS t3.medium maxes out around 3,000/sec
Need RDS r5.2xlarge: $730/month minimum
Still need read replicas: another $730/month

Application servers:

Each server handles ~1,000 req/sec (with caching)
Need 10 servers minimum
EC2 t3.medium × 10 = $300/month base
With load balancing and auto-scaling: around $500/month

Total monthly cost for 10K users with 1-second polling:

API Gateway:  $57,313
Bandwidth:    $1,170
Database:     $1,460
Servers:      $500
--------------------------
TOTAL:        $60,443/month

Per-user cost: $6.04/month

That's just infrastructure. Add development time debugging connection issues, rate limit errors, and database overload. I've seen teams burn two weeks fighting these problems.

Where polling breaks

Costs hurt, but they're not what kills you first. Polling dies from three hard limits.

Limit 1: Browser connection cap

Browsers allow 6 concurrent HTTP/1.1 connections per domain. Open 7 tabs with your app? Tab 7 hangs forever.

I've seen this kill deals. A hedge fund opens 20 price charts in separate tabs. Only 6 load. The rest show loading spinners eternally. They call it "broken" and cancel the trial. One team lost a $50K/year contract because of browser connection limits.

The math:

6 connection limit per domain
Each poll request holds a connection for 100-200ms
At 1-second polling: 6 connections × (1000ms / 150ms avg) = around 40 requests/sec max
Need faster updates? Hit the limit immediately

HTTP/2 helps but doesn't solve it. You still have connection overhead per request.

Limit 2: Rate limiting hell

You're not polling your own API. You're polling Binance, Coinbase, Kraken for prices. They have rate limits.

Binance rate limits:

1,200 requests/minute per IP
That's 20 req/sec
You have 10,000 users polling every second
You'd need 500 different IP addresses to stay under limit

CoinGecko Pro:

500 requests/minute with paid plan
10,000 users = you'd need 20 paid accounts
Cost: 20 × $129/month = $2,580/month just for rate limit headroom

Teams hit these limits at 50 concurrent users. They add exponential backoff, retry queues, distributed rate limiting. The code turns into spaghetti. I've watched teams spend a month untangling it.

Limit 3: Thundering herd on deploys

Here's a pattern I've analyzed multiple times. Team deploys new code. All servers restart. 10,000 connected clients lose their polling loops. They all reconnect simultaneously.

What happens:

T+0s:  10,000 clients reconnect
T+0s:  10,000 requests hit API at once
T+0s:  Load balancer sees spike, spawns more servers
T+2s:  New servers boot, load balancer adds them
T+2s:  Original servers already crashed from spike
T+4s:  New servers get 10,000 requests immediately, crash
T+6s:  Auto-scaling spawns MORE servers
T+10s: AWS bill climbing $500/hour from runaway scaling
T+30s: Engineer in console manually shutting down instances

I've seen this happen during routine 2 AM deploys. PagerDuty alerts, $2,000 AWS bill spikes, angry managers.

Streaming avoids this. Reconnections happen with exponential backoff and random jitter built-in. The load spreads over 30-60 seconds instead of hitting all at once.

What works instead

Once you accept polling is doomed, three patterns work.

SSE for simplicity

Server-Sent Events is HTTP with a persistent connection. Server pushes updates as they happen. Browser handles reconnection automatically.

Cost comparison for 10K users:

Polling (baseline):

25.9 billion requests/month
$60,443/month total cost

SSE:

10,000 persistent connections
Each connection: around 1 price update/second
Bandwidth: 10K × 500 bytes/sec × 2.6M sec = 13 TB (same as polling)
But: Only 10,000 initial connection requests (vs 25.9 billion!)
CloudFront + Lambda@Edge: roughly $1,200/month
Savings: $59,243/month (98% reduction)

I've seen teams migrate from polling to SSE in one weekend. Bill cuts by 95%. Connection code goes from 200 lines to 20.

Example using DexPaprika free SSE:

// Free SSE for crypto prices - no API key needed
const events = new EventSource(
  'https://streaming.dexpaprika.com/stream?method=t_p&chain=ethereum&address=0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48'
);

events.onmessage = (event) => {
  const data = JSON.parse(event.data);
  updatePrice(data.price);
};

// Browser handles reconnection automatically
// Last-Event-ID replay prevents data loss
// Works through corporate firewalls

When SSE wins:

Unidirectional data (server → client only)
Under 100K concurrent users
Enterprise customers (firewall friendly)
You need to ship fast

WebSocket for bidirectional needs

WebSocket creates a persistent TCP socket. Lower latency than SSE. Supports bidirectional communication. Better for trading apps.

Cost comparison for 10K users:

WebSocket infrastructure:

10,000 persistent connections
Binary encoding (MessagePack) reduces payload 60%
Bandwidth: 10K × 200 bytes/sec × 2.6M sec = around 5.2 TB/month
EC2 with uWebSockets.js: around $800/month (can handle 240K connections on one 16-core server)
Savings vs polling: $59,643/month (98.7% reduction)

But WebSocket adds complexity:

// WebSocket requires manual reconnection
class PriceFeed {
  constructor(url) {
    this.url = url;
    this.reconnectDelay = 1000;
    this.connect();
  }

  connect() {
    this.ws = new WebSocket(this.url);

    this.ws.onopen = () => {
      this.reconnectDelay = 1000;
      this.ws.send(JSON.stringify({
        subscribe: ['BTC-USD', 'ETH-USD']
      }));
    };

    this.ws.onmessage = (event) => {
      const data = JSON.parse(event.data);
      updatePrice(data);
    };

    this.ws.onclose = () => {
      // Exponential backoff prevents thundering herd
      const jitter = Math.random() * 1000;
      setTimeout(() => {
        this.connect();
        this.reconnectDelay = Math.min(this.reconnectDelay * 2, 30000);
      }, this.reconnectDelay + jitter);
    };
  }
}

When WebSocket wins:

Need bidirectional communication (trading, chat)
Binary data efficiency matters
Over 100K concurrent users
Mobile battery optimization critical

Hybrid approach (recommended pattern)

Don't pick one. Use both.

Many teams run SSE for public price feeds and WebSocket for authenticated trading. Different constraints, different tools.

Public price feeds (SSE):

No authentication needed
Works through firewalls
Browser auto-reconnect
Simple to implement
Free with DexPaprika

Authenticated trading (WebSocket):

Order placement needs bidirectional
Lower latency matters (sub-100ms)
Binary encoding reduces costs
Full control over connection

Cost breakdown for 10K users (hybrid):

SSE public feeds:     $800/month (8K users)
WebSocket trading:    $400/month (2K users)
---------------------------------
Total:                $1,200/month

vs Polling baseline:  $60,443/month
Savings:              $59,243/month (98%)

This isn't architectural purity. But it works. Infrastructure cost drops from $60K to $1.2K monthly. Same features. Better performance. Everyone sleeps better.

Migration path: from polling to streaming

You can't flip a switch. Here's how to do it without downtime.

First two weeks: Add streaming alongside polling

Deploy streaming endpoints. Don't remove polling yet. Run both in parallel.

// Feature flag for gradual rollout
const useStreaming = user.id % 100 < 10; // 10% of users

if (useStreaming) {
  connectSSE();
} else {
  startPolling();
}

Monitor error rates, connection stability, data consistency. Fix issues before expanding. Teams typically find bugs in the first week that would've crashed production with a full rollout.

Week 3: Increase streaming to 50%

Bump feature flag to 50%. Watch infrastructure costs drop. Handle edge cases:

Corporate firewalls blocking WebSocket? Fall back to SSE
SSE failing? Fall back to polling temporarily
Connection storms? Add random jitter to reconnect timing

This week reveals edge cases. Common issue: corporate proxies silently kill SSE connections after 60 seconds. Solution: Add keepalive pings.

Week 4-5: 100% streaming, keep polling as fallback

Flip everyone to streaming. Keep polling code as fallback for failures.

class ResilientPriceFeed {
  constructor() {
    this.failureCount = 0;
    this.maxFailures = 3;
  }

  connect() {
    try {
      this.sse = new EventSource(streamingURL);
      this.sse.onerror = () => {
        this.failureCount++;
        if (this.failureCount > this.maxFailures) {
          this.sse.close();
          this.fallbackToPolling();
        }
      };
    } catch (error) {
      this.fallbackToPolling();
    }
  }

  fallbackToPolling() {
    console.warn('Streaming failed, using polling fallback');
    this.pollInterval = setInterval(() => {
      fetch(pollingURL).then(updatePrices);
    }, 5000); // Slower than before, but works
  }
}

Eventually: Remove polling code (or don't)

Once streaming proves stable for a month, you can remove polling. But many teams keep the fallback. It saves them during outages. The extra code is worth the insurance.

When polling still makes sense

Don't cargo cult streaming. Polling works fine when:

Low frequency updates (> 30 seconds)

If you're updating prices every minute, polling is simpler:

1,000 users × 1 req/min × 60 min × 24 hr × 30 days = 43.2M requests/month
Cost: around $150/month

vs SSE infrastructure: around $200/month setup + maintenance

Under 1,000 users with 60-second updates? Poll away.

One-off requests

User clicks "refresh prices" manually? Use polling. Streaming makes no sense for user-triggered actions.

Internal tools

Building a dashboard for your 20-person team? Polling is fine. Don't over-engineer. I've seen teams waste weeks building streaming infrastructure for 5 concurrent users. Just poll.

Testing and development

Polling is easier to debug. Start with polling to prove your concept. Migrate to streaming when scale demands it. Many teams prototype with polling, switch to streaming around 200 users.

Decision framework: polling vs streaming

Here's how to decide:

Quick reference:

Users	Update Freq	Use Polling	Use Streaming
< 100	Any	Simple	Optional
100-1K	> 60s	Works	Optional
100-1K	< 60s	Gets expensive	Recommended
1K-10K	> 5 min	Barely works	Recommended
1K-10K	< 5 min	Will fail	Required
> 10K	Any	Don't even try	Required

Real-world migration results

Here's what the numbers look like for a typical portfolio tracker migration.

Before (polling at 1-second intervals):

Users: 8,500 concurrent
AWS monthly cost: $48,000
Average latency: 800ms
Error rate: 4% (mostly rate limits)
Database load: 95% CPU constant
Support tickets: 50/month about "slow prices"

After (SSE streaming):

Users: 8,500 concurrent (same)
AWS monthly cost: $1,100 (97.7% reduction)
Average latency: 150ms
Error rate: 0.1%
Database load: 15% CPU average
Support tickets: 2/month

Typical migration takes 3 weeks. Teams keep polling as fallback for 6 months (rarely need it). This kind of cost reduction can save a startup from running out of runway.

Free streaming changes everything

Here's what nobody talks about: cost isn't just infrastructure.

Traditional crypto data providers:

Binance WebSocket: Free but rate limited (20 req/sec)
CoinGecko Pro: $129/month for 500 req/min
CoinMarketCap: $499/month for real-time
Kaiko: $2,000+/month for institutional

For our 8,500 users:

Need around 150 req/sec minimum
Binance alone doesn't work (rate limits)
Would need 18 CoinGecko accounts = $2,322/month
Or one Kaiko enterprise plan = $5,000+/month

DexPaprika (Docs at docs.dexpaprika.com:

Free SSE streaming
No rate limits
No API key required
Over 21 milion tokens covered
33+ chains

Teams routinely cut costs from $50K/month to $1.1K/month by switching to free streaming. The savings are real.

Summary

1-second polling dies at scale. Not from one problem but from three: costs multiply with users, you hit hard limits (connections, rate limits), and thundering herd issues crash your infrastructure.

Streaming fixes all three. SSE cuts costs 95-98%. WebSocket goes further with binary encoding. Both eliminate connection limits and rate limit hell. Random reconnection jitter prevents thundering herd.

For most crypto apps, SSE is the right choice. Simpler than WebSocket, works through firewalls, browsers handle reconnection automatically. Free options like DexPaprika make it a no-brainer.

Start with polling if you're under 100 users. Migrate to streaming before you hit 1,000. Your infrastructure costs and sleep schedule will thank you.

Frequently asked questions

At what point should I migrate from polling to streaming?

When your monthly infrastructure cost exceeds $500 or you're seeing rate limit errors. For most apps, this happens around 500-1,000 concurrent users with sub-10 second polling intervals. Better to migrate early before costs spiral.

Can I mix polling and streaming in the same application?

Yes, and you should. Use polling for user-triggered actions (manual refresh, one-off queries) and streaming for continuous price feeds. Hybrid approaches work well. The key is using the right tool for each use case.

What if streaming fails? Do I need a polling fallback?

Yes for production apps. Keep polling as a fallback for when streaming connections fail. A common pattern: trigger fallback after 3 consecutive streaming failures and poll at a slower rate (30-60 seconds). This saves teams during outages.

How do I handle the migration without downtime?

Use feature flags. Roll out streaming to 10% of users first, monitor for a week, then increase gradually. Keep both systems running for 30 days minimum. See the migration path section above for a detailed timeline.

Is SSE really free with DexPaprika? What's the catch?

Yes, completely free. No API key, no rate limits, no credit card. The catch is it's DEX data (not centralized exchange data). For most crypto apps showing token prices, DEX data works fine. Teams report stable production usage.

Polling vs streaming for price updates: when each makes sense - Detailed comparison of both approaches
Server-Sent Events (SSE) explained for crypto apps - Deep dive into SSE implementation
SSE vs WebSockets: choosing the right transport for market data - Protocol comparison with decision framework

SSE vs WebSockets: choosing the right transport for market data

Mateusz Sroka — Wed, 28 Jan 2026 23:27:53 +0000

You need to stream crypto prices. Should you use SSE or WebSocket?

I've built both. I've crashed production with both. The decision isn't about features. It's about understanding what breaks at scale.

In this guide:

SSE vs WebSocket protocol comparison with real metrics
Decision framework for choosing between SSE and WebSocket
Production failure patterns and solutions from real deployments
Implementation examples with production-ready error handling
When to use hybrid approaches

Understanding the core difference

WebSockets create a bidirectional TCP socket. After the HTTP upgrade handshake, you get a different protocol entirely. Messages flow both ways with 2-6 bytes of overhead per frame. Browser and server can push whenever.

Server-Sent Events? Just HTTP. The server keeps the response open and pushes text events. Browser handles reconnection automatically. Each event looks like this: data: {"price": "45123.50"}\n\n. No protocol upgrade. No binary frames. No client messages.

That's the split. Everything else follows from this.

When SSE makes more sense

SSE works best for server-to-client flows where simplicity beats flexibility.

Unidirectional price feeds

Building a Bitcoin price ticker? SSE is perfect. Server pushes, client displays. Done:

// SSE client - 5 lines
const events = new EventSource('https://api.example.com/stream/btc-usd');
events.onmessage = (event) => {
  const price = JSON.parse(event.data);
  updatePriceDisplay(price.value);
};

WebSocket for the same thing? Twenty-five lines minimum:

// WebSocket client - reconnection hell
let ws;
let reconnectTimeout;

function connect() {
  ws = new WebSocket('wss://api.example.com/stream');

  ws.onopen = () => {
    clearTimeout(reconnectTimeout);
    ws.send(JSON.stringify({ subscribe: 'btc-usd' }));
  };

  ws.onmessage = (event) => {
    const price = JSON.parse(event.data);
    updatePriceDisplay(price.value);
  };

  ws.onclose = () => {
    reconnectTimeout = setTimeout(connect, 3000);
  };
}

connect();

I learned this the hard way. Built a whole WebSocket infrastructure for a read-only dashboard. Two months later, ripped it out for SSE. Saved 80% of the code.

Corporate firewall compatibility

Real story: A hedge fund client couldn't connect. Their SophosXG firewall blocked WebSocket upgrades silently. No errors, just... nothing. SSE worked immediately because it's plain HTTP.

This isn't rare. I've debugged connection issues with WatchGuard, McAfee, Fortinet, you name it. About 30% of enterprise customers have WebSocket problems. With SSE? Under 1%.

HTTP/2 multiplexing benefits

HTTP/2 changes the game for SSE. You can open 100 streams to the same domain without hitting browser limits. They multiplex over one TCP connection:

We discovered this accidentally. Customer opened 50 price feeds in different tabs. HTTP/1.1 SSE died at 6 connections. HTTP/2 handled all 50 without breaking a sweat.

Built-in reconnection with event replay

SSE's Last-Event-ID header is magic. Browser disconnects? It reconnects and sends the last ID it received. Your server replays missed events:

// Server-side event replay
app.get('/stream', (req, res) => {
  const lastEventId = req.headers['last-event-id'];

  // Replay what they missed
  if (lastEventId) {
    const missedEvents = getEventsSince(lastEventId);
    missedEvents.forEach(event => {
      res.write(`id: ${event.id}\n`);
      res.write(`data: ${JSON.stringify(event.data)}\n\n`);
    });
  }

  // Continue live
  subscribeToUpdates((data) => {
    res.write(`id: ${Date.now()}\n`);
    res.write(`data: ${JSON.stringify(data)}\n\n`);
  });
});

I didn't appreciate this until our WebSocket implementation lost 3 hours of trades during a network blip. The SSE backup? Zero data loss.

When WebSockets make more sense

WebSockets win when you need bidirectional communication, binary data, or extreme scale.

Order book streaming

Liquid crypto pairs generate 50-100 order book updates per second. Binary encoding matters:

// Order book update comparison
const update = {
  type: 'l2update',
  symbol: 'BTC-USD',
  bids: [[89123.50, 1.234], [89123.00, 2.456]],
  asks: [[89124.00, 0.987], [89124.50, 3.210]],
  sequence: 8674309
};

// Text (SSE): 198 bytes per update
// Binary (WebSocket + MessagePack): 67 bytes
// Savings: 66%

Do the math. Million updates per day, 10,000 traders. Binary WebSockets save 1.3 TB daily. That's real money in bandwidth costs.

Trading command execution

You can't place orders over SSE. It's receive-only. WebSocket handles both directions on one connection:

// Bidirectional trading
ws.send(JSON.stringify({
  action: 'place_order',
  side: 'buy',
  price: 89123.50,
  amount: 0.1,
  nonce: Date.now()
}));

ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  switch(msg.type) {
    case 'order_ack':
      showOrderConfirmation(msg.order_id);
      break;
    case 'price_update':
      updateOrderBookDisplay(msg.data);
      break;
    case 'execution':
      showFillNotification(msg.fill);
      break;
  }
};

Building this with SSE + REST? You're managing two connection types, synchronizing state, handling race conditions. I tried. Don't.

Mobile battery optimization

Controversial take: WebSocket beats SSE on mobile battery. Our tests:

WebSocket with 30s heartbeat: 6-8 hours streaming
SSE with auto-reconnect: 3-4 hours

Why? SSE reconnections wake the radio constantly. WebSocket keeps it in low-power mode between messages. But you MUST tune the heartbeat interval. Too frequent and you'll drain faster than SSE.

Scaling beyond 100K concurrent users

WebSocket servers scale better. Period. We pushed uWebSockets.js to 240,000 concurrent connections on a single 16-core box with sub-50ms latency. SSE? Capped around 50,000 before the event loop choked on response writes.

But here's the catch: you need engineers who understand epoll, buffer management, and backpressure. SSE scales worse but it's harder to screw up.

Production considerations and failure patterns

Both protocols will hurt you. Just differently.

SSE failure: proxy buffering disaster

True story. Production SSE stream working perfectly. Deploy behind nginx. Suddenly, 30-second delays on every price.

Nginx was buffering the entire response. Your 1-second updates queue until the buffer fills, then dump all at once. Users see nothing, then BOOM, 30 stale prices.

Fix this immediately:

location /stream {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";

    # These lines will save your job
    proxy_buffering off;
    proxy_cache off;
    proxy_read_timeout 3600s;
    chunked_transfer_encoding off;
    proxy_set_header X-Accel-Buffering no;
}

I've seen this kill three production launches. Check your proxy config first, always.

WebSocket failure: reconnection storms

Picture this. Your server restarts. 100,000 WebSocket clients disconnect simultaneously. They all reconnect immediately. Your server melts.

This happened at 3 AM. The ops team called it "the reconnection apocalypse."

Never do this:

// This will destroy your infrastructure
ws.onclose = () => {
  connect(); // Instant reconnect = instant death
};

Do this instead:

// Exponential backoff + random jitter
let reconnectDelay = 1000;
ws.onclose = () => {
  const jitter = Math.random() * 1000;
  setTimeout(() => {
    connect();
    reconnectDelay = Math.min(reconnectDelay * 2, 30000);
  }, reconnectDelay + jitter);
};

The jitter spreads reconnections over time. Saved us from buying 3x more servers.

SSE gotcha: browser connection limits

User opens 7 tabs with your SSE dashboard. Tab 7 never loads. Why? HTTP/1.1 allows 6 connections per domain. The 7th waits forever.

Ranked solutions:

Use HTTP/2 (multiplexing fixes this)
SharedWorker (tabs share one connection)
Domain sharding (ugly but works)
Connection pooling (complex but solid)

We went with HTTP/2. Took 10 minutes to enable. Solved forever.

WebSocket gotcha: transparent proxy timeouts

Corporate proxy kills idle WebSockets after 30 seconds. Your connection looks fine but messages vanish. Implement heartbeats or die:

// Server heartbeat
setInterval(() => {
  if (ws.readyState === WebSocket.OPEN) {
    ws.ping();
  }
}, 30000);

// Client response
ws.on('ping', () => {
  ws.pong();
  resetIdleTimer();
});

Miss one pong? Close and reconnect. Don't trust the connection state.

Real implementation: DexPaprika streaming

Let me show you production-ready implementations for both.

SSE implementation

class SSEPriceFeed {
  constructor(endpoint, symbols) {
    this.endpoint = endpoint;
    this.symbols = symbols;
    this.events = null;
    this.reconnectCount = 0;
  }

  connect() {
    const params = new URLSearchParams({
      chains: this.symbols.map(s => s.chain).join(','),
      tokens: this.symbols.map(s => s.address).join(',')
    });

    this.events = new EventSource(`${this.endpoint}?${params}`);

    this.events.onopen = () => {
      console.log('SSE connected');
      this.reconnectCount = 0; // Reset on success
    };

    this.events.onmessage = (event) => {
      try {
        const data = JSON.parse(event.data);
        this.handlePriceUpdate(data);
      } catch (error) {
        console.error('Parse error:', error);
        // Don't crash on bad data
      }
    };

    this.events.onerror = (error) => {
      console.error('SSE error:', error);
      this.reconnectCount++;

      // Browser reconnects automatically
      // But bail if it's clearly broken
      if (this.reconnectCount > 10) {
        this.events.close();
        this.fallbackToPolling();
      }
    };
  }

  handlePriceUpdate(data) {
    document.dispatchEvent(new CustomEvent('price-update', {
      detail: data
    }));
  }

  fallbackToPolling() {
    console.warn('SSE failed, polling fallback engaged');
    // Your polling code here
  }
}

// Using it
const feed = new SSEPriceFeed(
  'https://streaming.dexpaprika.com/stream',
  [
    { chain: 'ethereum', address: '0xa0b86991...' },
    { chain: 'bsc', address: '0xbb4cdb9...' }
  ]
);
feed.connect();

WebSocket implementation

class WebSocketPriceFeed {
  constructor(endpoint, symbols) {
    this.endpoint = endpoint;
    this.symbols = symbols;
    this.ws = null;
    this.reconnectDelay = 1000;
    this.pingInterval = null;
    this.pongTimeout = null;
  }

  connect() {
    this.ws = new WebSocket(this.endpoint);

    this.ws.onopen = () => {
      console.log('WebSocket connected');
      this.reconnectDelay = 1000; // Reset delay

      this.ws.send(JSON.stringify({
        type: 'subscribe',
        symbols: this.symbols
      }));

      this.startHeartbeat();
    };

    this.ws.onmessage = (event) => {
      // Handle both binary and text
      if (event.data instanceof Blob) {
        event.data.arrayBuffer().then(buffer => {
          const data = msgpack.decode(new Uint8Array(buffer));
          this.handlePriceUpdate(data);
        });
      } else {
        const data = JSON.parse(event.data);

        if (data.type === 'pong') {
          this.handlePong();
        } else {
          this.handlePriceUpdate(data);
        }
      }
    };

    this.ws.onclose = (event) => {
      console.log('WebSocket closed:', event.code, event.reason);
      this.stopHeartbeat();
      this.scheduleReconnect();
    };

    this.ws.onerror = (error) => {
      console.error('WebSocket error:', error);
      // onclose will fire next, handle reconnect there
    };
  }

  startHeartbeat() {
    this.pingInterval = setInterval(() => {
      if (this.ws.readyState === WebSocket.OPEN) {
        this.ws.send(JSON.stringify({ type: 'ping' }));

        // If no pong in 10 seconds, it's dead
        this.pongTimeout = setTimeout(() => {
          console.error('Pong timeout, connection dead');
          this.ws.close();
        }, 10000);
      }
    }, 30000);
  }

  handlePong() {
    clearTimeout(this.pongTimeout);
  }

  stopHeartbeat() {
    clearInterval(this.pingInterval);
    clearTimeout(this.pongTimeout);
  }

  scheduleReconnect() {
    // Random jitter prevents thundering herd
    const jitter = Math.random() * 1000;
    setTimeout(() => {
      this.connect();
      // Exponential backoff up to 30 seconds
      this.reconnectDelay = Math.min(this.reconnectDelay * 2, 30000);
    }, this.reconnectDelay + jitter);
  }

  handlePriceUpdate(data) {
    document.dispatchEvent(new CustomEvent('price-update', {
      detail: data
    }));
  }
}

// Using it
const feed = new WebSocketPriceFeed(
  'wss://api.example.com/stream',
  ['ethereum:0xa0b86991...', 'bsc:0xbb4cdb9...']
);
feed.connect();

Making the decision

Start with SSE unless you absolutely need WebSocket features.

I know that's not the nuanced answer you wanted. But after debugging connection issues at 3 AM too many times, simplicity wins. SSE gets you 80% there with 20% of the complexity. You can ship a production SSE client in 20 lines. WebSocket? You need 100+ lines to handle the edge cases properly.

Choose WebSocket when you actually need it: bidirectional communication, binary data, mobile optimization, or proven scale past 100K users. Not before.

And honestly? Consider hybrid approaches. We use SSE for public price feeds (simple, firewall-friendly) and WebSocket for authenticated trading (bidirectional, low latency). It's not architecturally pure. But it works.

Test your choice with real conditions. Stream through corporate proxies. Kill your servers mid-stream. Open 50 tabs. Use 3G mobile connections. What works locally might explode when that hedge fund with ancient proxy infrastructure becomes your biggest customer.

Summary

SSE and WebSockets both stream real-time data. SSE uses standard HTTP for simplicity and compatibility. WebSocket creates a new protocol for efficiency and flexibility.

Pick SSE for unidirectional feeds, enterprise environments, and when you want to ship fast. Pick WebSocket for bidirectional needs, binary data, and massive scale. Both handle crypto price feeds fine. Your constraints determine the right choice.

But really, pick the one that lets you sleep at night.

Frequently asked questions

Can I use both SSE and WebSocket in the same application?

Yes, and I recommend it. SSE for public feeds, WebSocket for authenticated operations. We run both in production. Works great.

How do SSE and WebSocket handle disconnections differently?

SSE reconnects automatically with exponential backoff. Browser sends Last-Event-ID for replay. WebSocket? You build everything yourself. More control, more work.

Which protocol works better through corporate proxies?

SSE, no contest. It's HTTP. WebSocket gets blocked by paranoid firewalls constantly. Lost a Fortune 500 deal once because their security team wouldn't allow WebSocket. Learned that lesson.

What are the actual bandwidth differences between SSE and WebSocket?

For small JSON messages? Nearly identical. SSE adds ~10 bytes for data: prefix. WebSocket adds 2-6 bytes for framing. But binary data? WebSocket crushes SSE. 60-70% smaller for order books.

Should I use polling instead of streaming for simple price displays?

If you're updating every 30+ seconds with under 100 users, sure, poll away. Simpler is better. But once you need updates faster than 10 seconds or have 100+ concurrent users, streaming pays off. See Polling vs streaming for price updates: when each makes sense for the full breakdown.

Server-Sent Events (SSE) explained for crypto apps (with real examples)

Mateusz Sroka — Thu, 22 Jan 2026 19:19:31 +0000

Most teams building crypto price feeds reach for WebSockets. It feels right: real-time data needs real-time protocols. But WebSockets are overkill for 80% of crypto price feeds. If your data flows one direction (server → client), Server-Sent Events (SSE) is simpler, more reliable, and works in 10 lines of code.

I've seen teams spend three days debugging WebSocket reconnection logic. SSE handles reconnections automatically. I'll show you why SSE might be the better choice for your crypto app.

What is SSE (and why it matters for crypto feeds)

Server-Sent Events is an HTTP-based protocol where the server holds a connection open and pushes data to the client whenever it has updates. Think of it like a one-way radio broadcast: the server talks, the client listens.

For crypto price feeds, that's exactly what you need. Prices update on the server (from DEX aggregators, oracles, or market data), and you push those updates to connected clients. You don't need clients sending data back to the server for price feeds.

How SSE works under the hood:

The client makes a standard HTTP GET request with Accept: text/event-stream. The server responds with 200 OK and a special Content-Type: text/event-stream header. The connection stays open, and the server writes newline-delimited messages whenever it has updates.

The message format is simple:

data: {"token":"WETH","price":"3245.67"}

data: {"token":"USDC","price":"0.9998"}

Each message starts with data:, followed by your payload (usually JSON), then two newlines (\n\n). No binary protocols, no handshake complexity, just HTTP and text.

What makes SSE good for crypto feeds:

Automatic reconnection - Browser handles reconnects with exponential backoff built-in
Event IDs for recovery - Server can send id: field, browser remembers last ID and resumes from there
Works through proxies - It's just HTTP, so corporate firewalls and CDNs pass it through
No library needed - EventSource API is built into every modern browser
Simpler debugging - You can test with curl -N, messages are readable text

What SSE can't do (and why that's fine):

Client can't send messages back through the SSE connection (use regular HTTP POST if needed)
Binary data requires base64 encoding (WebSocket handles binary natively)
Not designed for bidirectional protocols (game state, collaborative editing)

For crypto price feeds, you rarely need the client to send data upstream through the same connection. Watching prices is a one-way flow. When a user wants to execute a trade, that's a separate HTTP POST to your trading API. SSE + REST covers 90% of crypto app needs.

Your first SSE connection (10 lines with DexPaprika)

Let's connect to a real crypto price feed. We'll use DexPaprika's free SSE endpoint: no credit card, no API key, just working code.

Goal: Stream live Ethereum WETH prices

const eventSource = new EventSource(
  'https://streaming.dexpaprika.com/stream?method=t_p&chain=ethereum&address=0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2'
);

eventSource.addEventListener('t_p', (event) => {
  const data = JSON.parse(event.data);
  console.log(`${data.c}: $${data.p} at ${new Date(data.t * 1000).toLocaleTimeString()}`);
});

eventSource.onerror = (error) => {
  console.error('Connection error:', error);
  // Browser automatically reconnects
};

What this does:

new EventSource(url) - Opens HTTP connection to DexPaprika's streaming endpoint
addEventListener('t_p', ...) - Listens for price events (DexPaprika sends event: t_p)
JSON.parse(event.data) - Parse the price payload
onerror - Handle connection errors (browser will retry automatically)

The URL breakdown:

streaming.dexpaprika.com/stream - DexPaprika's SSE endpoint
method=t_p - Token price method
chain=ethereum - Which blockchain
address=0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 - WETH contract address

Run this in your browser console (F12) and you'll see live prices:

ethereum: $3245.67 at 2:34:12 PM
ethereum: $3246.01 at 2:34:13 PM
ethereum: $3245.89 at 2:34:14 PM

Ten lines of code, no authentication, no complex setup. The connection stays open, and prices update about once per second.

Compare this to WebSocket complexity:

// WebSocket version (25+ lines for same functionality)
const ws = new WebSocket('wss://example.com/stream');

ws.onopen = () => {
  ws.send(JSON.stringify({
    action: 'subscribe',
    channel: 'prices',
    token: 'WETH'
  }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log(data.price);
};

ws.onerror = (error) => {
  console.error(error);
  // Manual reconnection logic needed
  setTimeout(() => {
    // Reconnect logic here (10+ more lines)
  }, 1000);
};

ws.onclose = () => {
  // Also need manual reconnection here
};

With WebSocket, you have to:

Send a subscription message after connecting
Write your own reconnection logic (exponential backoff, max retries)
Handle state recovery (what was I subscribed to?)
Debug binary frames or JSON over WebSocket protocol

With SSE, the browser does all of that for you.

Handling reconnects and errors in production

The browser's automatic reconnection is good, but production apps need more control. You want exponential backoff, connection state tracking, and graceful degradation.

Production-ready SSE wrapper:

class ResilientSSE {
  constructor(url, options = {}) {
    this.url = url;
    this.eventSource = null;
    this.reconnectDelay = 1000; // Start at 1 second
    this.maxReconnectDelay = 30000; // Max 30 seconds
    this.reconnectAttempts = 0;
    this.listeners = new Map();
    this.onConnect = options.onConnect || (() => {});
    this.onError = options.onError || (() => {});
  }

  connect() {
    this.eventSource = new EventSource(this.url);

    this.eventSource.onopen = () => {
      console.log('SSE connected');
      this.reconnectDelay = 1000; // Reset backoff
      this.reconnectAttempts = 0;
      this.onConnect();
    };

    this.eventSource.onerror = (error) => {
      console.error('SSE error:', error);
      this.onError(error);

      // Browser will reconnect automatically, but we track attempts
      this.reconnectAttempts++;

      // Exponential backoff: 1s, 2s, 4s, 8s, 16s, 30s (max)
      this.reconnectDelay = Math.min(
        this.reconnectDelay * 2,
        this.maxReconnectDelay
      );

      console.log(`Will reconnect in ${this.reconnectDelay}ms (attempt ${this.reconnectAttempts})`);
    };

    // Re-attach all listeners
    for (const [eventType, handler] of this.listeners) {
      this.eventSource.addEventListener(eventType, handler);
    }
  }

  on(eventType, handler) {
    this.listeners.set(eventType, handler);
    if (this.eventSource) {
      this.eventSource.addEventListener(eventType, handler);
    }
  }

  close() {
    if (this.eventSource) {
      this.eventSource.close();
      this.eventSource = null;
    }
  }
}

Using the wrapper:

const priceStream = new ResilientSSE(
  'https://streaming.dexpaprika.com/stream?method=t_p&chain=ethereum&address=0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2',
  {
    onConnect: () => {
      console.log('Price feed connected');
      updateUI('connected');
    },
    onError: (error) => {
      console.error('Price feed error:', error);
      updateUI('reconnecting');
    }
  }
);

priceStream.on('t_p', (event) => {
  const data = JSON.parse(event.data);
  updatePriceDisplay(data.c, data.p);
});

priceStream.connect();

This wrapper gives you:

Exponential backoff (1s → 2s → 4s → 8s → 16s → 30s max)
Connection state callbacks (show "reconnecting" in UI)
Listener management (re-attach handlers on reconnect)
Clean shutdown (close connections properly)

Why exponential backoff matters:

Without backoff, if your server restarts and 10,000 clients all reconnect instantly, you create a "thundering herd." Your server gets slammed with 10,000 simultaneous connections and crashes again. I've seen this cause 15+ minute outages.

With exponential backoff and jitter (random delay), those 10,000 clients reconnect over 30 seconds instead of 100ms. Server stays stable, users get their data back faster.

Streaming multiple assets (scaling to hundreds of tokens)

One EventSource connection handles one stream. For a single token, that's perfect. But what if you're building a portfolio tracker with 50 tokens? Opening 50 separate SSE connections is inefficient.

DexPaprika's POST endpoint lets you subscribe to multiple assets in one stream:

async function streamMultipleAssets(tokens) {
  const response = await fetch('https://streaming.dexpaprika.com/stream', {
    method: 'POST',
    headers: {
      'Accept': 'text/event-stream',
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(tokens)
  });

  if (!response.ok) {
    throw new Error(`HTTP ${response.status}: ${await response.text()}`);
  }

  const reader = response.body.getReader();
  const decoder = new TextDecoder();
  let buffer = '';

  while (true) {
    const {done, value} = await reader.read();
    if (done) break;

    buffer += decoder.decode(value, {stream: true});
    const lines = buffer.split('\n');

    // Keep last incomplete line in buffer
    buffer = lines.pop() || '';

    for (const line of lines) {
      if (line.startsWith('data: ')) {
        const data = JSON.parse(line.slice(6));
        handlePriceUpdate(data);
      }
    }
  }
}

// Subscribe to 3 tokens across different chains
streamMultipleAssets([
  {chain: 'ethereum', address: '0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2', method: 't_p'}, // WETH
  {chain: 'solana', address: 'So11111111111111111111111111111111111111112', method: 't_p'},   // SOL
  {chain: 'ethereum', address: '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48', method: 't_p'}  // USDC
]);

function handlePriceUpdate(data) {
  console.log(`${data.c} on ${data.chain}: $${data.p}`);
  updatePortfolio(data.a, data.p);
}

Key differences from GET method:

Use fetch() instead of EventSource - EventSource API only supports GET
Parse the stream manually - Read response.body as a stream, split by newlines
Handle incomplete messages - Keep a buffer for partial lines
Single connection for all assets - Much more efficient than N connections

Limits and best practices:

Max 2,000 tokens per request (DexPaprika limit)
Recommended: 100-500 tokens per request (better performance and error recovery)
All assets must be valid - If ANY token address is wrong, entire stream fails with 400 error

If you need 1,500 tokens, split into 3 requests of 500 each. You get:

Better load distribution across DexPaprika servers
Partial success (2 streams work even if 1 fails)
Easier debugging (smaller payload per connection)

Browser quirks and production failures (what actually breaks)

SSE is simple, but production has edge cases. I researched real failures from Stack Overflow, GitHub issues, and engineering blogs. Here are the patterns that actually break in production.

1. Proxy buffering (5-10% of corporate users hit this)

Symptom: Some users report prices being "stuck" for 20+ minutes, then suddenly jumping.

Root cause: HTTP proxies are allowed to buffer responses. Some corporate proxies buffer the entire text/event-stream response, not releasing data to the client until the connection closes.

Detection:

let lastUpdate = Date.now();

priceStream.on('t_p', (event) => {
  const delay = Date.now() - lastUpdate;
  if (delay > 10000) {
    console.warn(`Delayed update: ${delay}ms (proxy buffering?)`);
    reportTelemetry('sse_delayed_update', {delay});
  }
  lastUpdate = Date.now();
});

Solution: Offer a long-polling fallback for users with delays > 10 seconds:

if (detectedProxyBuffering) {
  // Fall back to polling every 5 seconds
  setInterval(() => {
    fetch('/api/prices').then(res => res.json()).then(updatePrices);
  }, 5000);
}

2. Browser connection limit (hits users opening 7+ tabs)

Symptom: Opening a 7th tab of your app causes the first 6 tabs to stop receiving updates.

Root cause: Browsers limit HTTP/1.1 connections to 6 per domain (Chrome, Firefox, Safari). EventSource uses one connection per stream. Opening 7 tabs = 7 connections = limit exceeded.

Solution options:

Option A: Use HTTP/2 (supports 100+ concurrent streams):

// Server must support HTTP/2
// No client-side changes needed, just deploy with HTTP/2 enabled

Option B: Share connection across tabs with BroadcastChannel:

const channel = new BroadcastChannel('price_updates');
let isLeaderTab = false;

// Leader election: first tab becomes leader
if (!localStorage.getItem('leader_tab')) {
  localStorage.setItem('leader_tab', Date.now());
  isLeaderTab = true;
}

if (isLeaderTab) {
  // Only leader tab opens SSE connection
  priceStream.on('t_p', (event) => {
    channel.postMessage(event.data);
  });
} else {
  // Follower tabs listen to BroadcastChannel
  channel.onmessage = (event) => {
    const data = JSON.parse(event.data);
    updatePriceDisplay(data.c, data.p);
  };
}

3. nginx proxy timeout (100% of users behind default nginx config)

Symptom: SSE connection drops exactly every 60 seconds, then reconnects.

Root cause: nginx default proxy_read_timeout is 60 seconds. If no data flows for 60s, nginx closes the connection.

Server-side fix (nginx configuration):

location /stream {
    proxy_pass http://backend;
    proxy_read_timeout 3600s;  # 1 hour
    proxy_buffering off;       # Critical for SSE
    proxy_set_header Connection '';
    proxy_http_version 1.1;
    chunked_transfer_encoding off;
}

Client-side workaround: If you don't control the proxy, send heartbeat comments every 30 seconds:

// Server sends this every 30 seconds
: heartbeat

// Comments (lines starting with :) are ignored by EventSource
// But they keep the connection alive through proxies

4. Safari mobile idle timeout (iOS battery optimization)

Symptom: On iOS, SSE connections close after ~5 minutes when the app is in background.

Root cause: Safari closes idle network connections to save battery.

Solution: Accept this limitation and reconnect when app returns to foreground:

document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'visible' && !priceStream.eventSource) {
    priceStream.connect();
  }
});

When SSE makes sense (decision framework)

Use SSE when:

Criteria	Why SSE wins
Data flows server → client only	Built for this pattern
You want automatic reconnection	Browser handles it
You're behind corporate proxies/firewalls	Just HTTP, no WebSocket upgrade negotiation
You want to test with curl	`curl -N url` shows live events
Team is learning real-time	Simpler than WebSocket

Use WebSocket when:

Criteria	Why WebSocket wins
Bidirectional communication needed	SSE is one-way only
You need binary data	SSE is text-based (base64 overhead for binary)
Sub-second latency critical	WebSocket has slightly lower overhead
Mobile apps (not web)	Native WebSocket support often better

For crypto price feeds specifically:

Most crypto apps fall into SSE territory:

Prices flow server → client (one-way)
Updates every 1-3 seconds are fine (not sub-100ms)
Users watch prices, execute trades via separate API calls (not bidirectional)
Developer experience matters (SSE is simpler to implement and debug)

I'd estimate 80% of crypto price feed use cases are better served by SSE than WebSocket. The 20% that need WebSocket are usually trading platforms where users send order updates upstream through the same connection.

Summary: SSE is simpler than you think

Server-Sent Events gives you real-time crypto price feeds without WebSocket complexity:

10 lines of code to connect to a live stream (no library needed)
Automatic reconnection with exponential backoff (browser handles it)
Works through proxies (it's just HTTP)
Free with DexPaprika (no credit card, no API key)

The production failures are manageable:

Add heartbeats every 30s (nginx timeout fix)
Detect proxy buffering, fall back to polling if needed
Use HTTP/2 or BroadcastChannel for multi-tab apps
Accept iOS background limitations (reconnect on foreground)

For most crypto apps, SSE + REST covers everything you need. When a user wants to watch prices, use SSE. When they want to execute a trade, use a regular HTTP POST. You don't need full-duplex bidirectional communication for 80% of use cases.

Try DexPaprika's free SSE endpoint:

Documentation: https://docs.dexpaprika.com/streaming
Single asset: https://streaming.dexpaprika.com/stream?method=t_p&chain=ethereum&address=0x...
Multiple assets: POST to https://streaming.dexpaprika.com/stream
1,300+ tokens across 20+ chains
No authentication required

Start with the 10-line example from this article. Add the production wrapper when you need reconnection control. Use the POST method when tracking multiple tokens. You'll have a production-ready crypto price feed running in an afternoon.

FAQ

Q: Can I use EventSource with authentication headers?

No, the EventSource API doesn't support custom headers. If you need authentication, use fetch() with Accept: text/event-stream and parse the stream manually (like the multiple-asset example). Or pass auth tokens as URL query parameters (less secure, but works with EventSource).

Q: How do I know if SSE is working behind my corporate proxy?

Connect to a test stream and log the time between updates. If you see 20+ second gaps when expecting 1-second updates, you're likely hitting proxy buffering. Check navigator.connection.effectiveType and fall back to polling for users on slow/buffered connections.

Q: What happens if my server restarts?

The client's SSE connection breaks, the browser automatically reconnects with exponential backoff. If your server sends id: <message_id> with each event, the browser includes Last-Event-ID header on reconnection. Your server can resume from that ID instead of sending all historical data.

Q: Can I send binary data over SSE?

SSE is text-based. You can base64-encode binary data, but that adds 33% overhead. For crypto price feeds (JSON objects with numbers), this doesn't matter. For chart data or large datasets, consider WebSocket or HTTP/2 Server Push.

Q: Is SSE supported in all browsers?

Yes, in all modern browsers (Chrome, Firefox, Safari, Edge). Check current browser compatibility on MDN. Internet Explorer 11 doesn't support it, but IE11 market share is < 1% in 2026. For legacy support, use a polyfill or fall back to long polling.

Disclosure

I work at CoinPaprika and DexPaprika. All code examples in this article use DexPaprika's SSE streaming endpoint because it's genuinely the best way to demonstrate SSE for crypto prices: it's free, requires no authentication, and covers 1,300+ tokens across 20+ chains.

I've tested competitors (several charge $500-5,000/month for similar streaming). DexPaprika's "completely free, no credit card" approach is why I use it in tutorials.

The technical advice in this article (SSE mechanics, browser quirks, production failures) applies regardless of which API you use.

Polling vs streaming for crypto prices: when each makes sense

Mateusz Sroka — Wed, 21 Jan 2026 11:45:51 +0000

I spent months helping teams pick between polling and streaming for their crypto apps. Most assumed streaming was always better: faster, more "real-time," more professional. Then I'd ask about their user count. 50 users. 60-second update frequency. Standard shared hosting.

They were about to spend 2 weeks building WebSocket infrastructure for a problem polling solves in 2 days.

The choice between polling (making repeated HTTP requests) and streaming (keeping a persistent connection open) depends on your update frequency, user scale, infrastructure, and team experience. Neither approach wins universally.

You'll learn:

When polling actually makes more sense than streaming
Real costs at different scales (50 users vs 5,000 users)
Production failures I've seen with both approaches
How to migrate between them without downtime

Disclosure: I work at CoinPaprika/DexPaprika, so the code examples use our APIs. Everything here applies to any polling or streaming implementation.

What you're choosing between

Polling: Your client asks "what's the price?" every N seconds. The server responds. Your client waits. Repeats. Simple, stateless, works everywhere.

Streaming: Your client opens a connection and says "tell me when the price changes." The server pushes updates. Connection stays open. Lower latency, more complexity.

Both keep your users informed of price changes. The trade-offs differ:

Latency: Polling = 0 to 1× your interval. 30-second polling means 0-30 seconds of staleness. Streaming = sub-second. (I measured this in What "Real-Time Crypto Prices" Actually Means)
Cost: Polling scales with users × requests. At 5,000 users with 30-second polling, you're making 10,000 requests per minute. Streaming has fixed overhead but lower per-user cost at scale.
Complexity: Polling = standard HTTP. Test with curl. Debug with logs. Streaming = connection lifecycle, reconnect logic, heartbeat monitoring.
Team learning: Polling took me 2 days to ship production-ready. Streaming took 2 weeks to handle all the edge cases.

A portfolio tracker with 50 users checking prices every minute doesn't need the same architecture as a trading dashboard with 5,000 users needing sub-second updates.

How polling works

You make periodic HTTP requests to check for new data. Your client sends a request every N seconds, gets current prices back, waits, repeats.

Basic polling in JavaScript:

// Poll DexPaprika API every 30 seconds (verified Dec 23, 2025)
const POLL_INTERVAL = 30000; // 30s in milliseconds

async function pollPrices() {
  try {
    // DexPaprika REST API: /networks/{network}/tokens/{address}
    const response = await fetch('https://api.dexpaprika.com/networks/ethereum/tokens/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2');
    const data = await response.json();
    updateUI(data.summary.price_usd);
  } catch (error) {
    console.error('Poll failed:', error);
    // Production: add exponential backoff, circuit breaker
  }
}

setInterval(pollPrices, POLL_INTERVAL);

Each request is independent. If one fails, the next poll gets fresh data. No connection state to manage, no reconnect logic.

Production code needs exponential backoff for failures, jitter to avoid thundering herds (all clients polling simultaneously), and rate limit handling. The core stays simple: request, wait, repeat.

When polling is the right choice

Infrequent updates (30+ seconds acceptable)

Portfolio trackers showing daily P&L don't need sub-second prices. 30-60 second polling provides sufficient freshness. The overhead is negligible.

Personal finance app with 200 users, 60s polling = 200 requests/minute total. Any server handles this easily.

Small user base (< 100 concurrent users)

At 100 users with 30s polling, you're making ~200 requests/minute. Infrastructure cost: ~$30-50/month on standard hosting. Streaming infrastructure would cost more ($75-100/month for WebSocket-capable load balancers, connection management).

The crossover where streaming becomes cost-effective is around 800-1,000 users.

Standard infrastructure

Polling works with any HTTP server. No WebSocket support needed, no connection pooling, no special load balancer config. Shared hosting, standard CDNs, basic reverse proxies all work.

If your infrastructure doesn't support persistent connections, polling is your only option without an upgrade.

Team new to real-time systems

Polling is stateless HTTP, the same pattern used everywhere on the web. Developers learn it in days. Testing: curl works. Debugging: check HTTP logs. Error handling: retry the request.

Streaming requires understanding connection lifecycle, reconnect strategies, heartbeat logic, and stateful debugging. Learning curve: 1-2 weeks for production-ready.

Trade-offs you're making

Polling gives you:

Standard HTTP requests. No connection state, no lifecycle management. Test with curl, debug with HTTP logs.
Works with any web server, load balancer, CDN, or caching layer. No special configuration.
Predictable costs. N users × M requests/minute = clear bandwidth usage. Linear scaling makes budgeting simple.
Stateless debugging. Each request is independent. Failures don't cascade. Test individual requests in isolation.

Polling costs you:

Higher latency. Data freshness ranges from 0 (just polled) to 1× your interval (about to poll). 30s polling means 0-30s stale data. Users see price movement late.
Wasted bandwidth. Polling during periods of no change sends identical responses repeatedly. Bitcoin staying at $43,500 for 10 minutes? Your 30s polling sent 20 identical responses.
Rate limit pressure. Frequent polling exhausts API quotas fast. If your provider limits you to 10,000 requests/hour, 100 users at 10s polling = 36,000 requests/hour (360% over limit).
Server load spikes. Without jitter, all clients poll simultaneously. 1,000 users starting at midnight means 1,000 requests hit your server within milliseconds every 30s.

At 50 users with 60s polling, simplicity outweighs minimal latency cost. At 5,000 users with 5s polling, you're burning $5,000/month in bandwidth that streaming would reduce to $400/month.

How streaming works

You establish a persistent connection between client and server. Instead of the client requesting data repeatedly, the server pushes updates as they occur. The connection stays open indefinitely (or until network failure).

For browser crypto apps, Server-Sent Events (SSE) is common:

// Stream price updates via SSE (verified Dec 23, 2025)
// DexPaprika Streaming API: /stream?method=t_p&chain={chain}&address={address}
const eventSource = new EventSource('https://streaming.dexpaprika.com/stream?method=t_p&chain=ethereum&address=0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2');

eventSource.addEventListener('t_p', (event) => {
  const data = JSON.parse(event.data);
  updateUI(data.p); // Update immediately when price changes
});

eventSource.onerror = (error) => {
  console.error('Connection failed:', error);
  // Production: exponential backoff reconnect
  // Production: switch to polling fallback after N failures
};

// Connection stays open, server pushes updates as prices change

The connection persists across multiple updates. Bitcoin's price changes 10 times in a minute? You receive 10 messages over one connection. No new HTTP requests.

Production code adds reconnect logic with exponential backoff, heartbeat monitoring (detect silent disconnects), connection health checks, and fallback to polling during extended outages. Core pattern: connect once, receive updates as they happen.

When streaming is the right choice

Fast updates (< 5 seconds)

Trading dashboards need prices within 1-2 seconds of market movement. Polling at 2s intervals creates visible lag and hammers your API (30 requests/minute per user). Streaming delivers updates in 100-500ms.

Active trading app with 500 users. Streaming = 500 connections, updates pushed as prices change. Polling at 2s = 15,000 requests/minute (rate limit nightmare).

Moderate to high users (> 1,000 concurrent)

At 1,000+ users, bandwidth costs favor streaming. Polling sends full state every interval. Streaming sends only changes.

Cost at 1,000 users (30s updates):

Polling: 2,000 requests/minute × ~1KB response = ~120GB/month = $500/month
Streaming: 1,000 connections × ~10KB/hour = ~7GB/month = $150/month

Crossover: ~800 users. Below that, polling is cheaper. Above, streaming wins.

Infrastructure supports persistent connections

Modern cloud platforms (AWS ALB, GCP Load Balancing, Cloudflare) support WebSocket and SSE. If your infrastructure is already capable, the barrier is lower.

Check your load balancer's connection limits. Default nginx: 1,024 connections. At 1,000 users, you're at 97% capacity. Configure higher limits.

Team comfortable with connection management

Streaming requires handling reconnects, exponential backoff, heartbeats, and monitoring active connections. Teams with prior WebSocket experience ship production-ready streaming in 1-2 weeks.

Teams new to persistent connections face 2-4 weeks to handle edge cases (silent disconnects, connection storms after outages, proxy timeouts).

Trade-offs you're making

Streaming gives you:

Low latency. Updates arrive in 100-500ms, not 0-30s. Users see price changes immediately. Critical for trading, real-time charts, urgent alerts.
Bandwidth efficiency. Only transmit when prices change. Bitcoin stays at $43,500 for 10 minutes? Streaming sends zero data. Polling sends 20 identical responses.
Real-time push. Server can send urgent updates (flash crashes, circuit breakers) without client requesting. Polling requires clients to discover updates on next poll.
Better UX at scale. Smooth, responsive interface. No visible polling lag. Prices update fluidly.

Streaming costs you:

Infrastructure complexity. Need WebSocket-capable load balancers, connection pooling, proxy timeout configuration. Default nginx proxy_read_timeout is 60s. Your connection drops after 1 minute without configuration.
Debugging difficulty. Connections are stateful. Can't test with curl. Need tools like wscat or browser DevTools. Reproducing connection-specific bugs is harder.
Connection management. Reconnect logic, exponential backoff, jitter, heartbeat monitoring, graceful shutdown. Each adds complexity and failure modes.
Higher cost at low scale. Connection infrastructure costs $75-100/month even at 10 users. Polling at 10 users costs $5-10/month. Streaming only becomes cost-effective at ~800+ users.

At 5,000 users with sub-second latency needs, streaming saves $4,600/month versus polling and delivers better UX. At 50 users with 60s updates, streaming adds unnecessary complexity.

Side-by-side comparison

Dimension	Polling	Streaming
Latency	0.5× to 1× polling interval (30s polling = 0-30s delay)	< 1 second (typically 100-500ms)
Bandwidth	High (full state every interval, even if unchanged)	Low (only send when data changes)
Complexity	Low (standard HTTP, stateless)	Medium (connection lifecycle, reconnect logic)
Infrastructure	Any HTTP server, standard load balancer	WebSocket-capable LB, connection pools, timeout config
Debugging	Easy (`curl` works, HTTP logs, stateless)	Harder (stateful, need `wscat`, connection-aware tools)
Cost at 100 users	$30-50/month (bandwidth for 30s polling)	$75-100/month (infrastructure overhead)
Cost at 1,000 users	$400-500/month (bandwidth costs)	$150/month (efficient updates)
Cost at 10,000 users	$5,000/month (bandwidth + rate limit upgrades)	$400/month (scales linearly)
Rate limits	High impact (N users × M req/min)	Low impact (1 connection per user, data sent only on change)
Learning curve	1-2 days	1-2 weeks for production-ready

The cost crossover happens around 800-1,000 users. Below that, polling is cheaper. Above, streaming's bandwidth efficiency wins.

Latency is the clearest differentiator. If you need < 5s updates, streaming is effectively required. Polling at 5s intervals creates 0-5s staleness and high request rates.

Infrastructure matters. On shared hosting without WebSocket support, polling is your only option without infrastructure changes.

Team skills affect time-to-market. Polling ships in days. Streaming needs 1-2 weeks to handle reconnects, monitoring, edge cases.

When to use polling vs streaming

Use polling when:

Update frequency > 30 seconds works
- Portfolio tracker showing daily P&L
- 100 users at 60s polling = ~$30/month
User base < 100 concurrent
- Internal company dashboard
- Infrastructure simplicity outweighs bandwidth costs
- Streaming would cost more ($75 vs $30) for minimal benefit
You need simple infrastructure
- Shared hosting, standard CDN, basic reverse proxy
- No WebSocket support needed
- Migration to WebSocket-capable hosting: $50-200/month
Team is new to real-time
- Small dev team, first real-time feature
- Lower risk, faster shipping (1-2 days vs 1-2 weeks)
- Learn with polling, migrate to streaming when proven

Use streaming when:

Update frequency < 5 seconds required
- Live trading dashboard, real-time price charts
- 1,000 users at 5s polling = 12,000 req/min (unsustainable)
User base > 1,000 concurrent
- Public crypto price tracker
- Bandwidth savings offset infrastructure complexity
- Savings: $350/month at 1,000 users, $4,600/month at 10,000 users
Infrastructure supports WebSocket
- AWS ALB, GCP Load Balancing, Cloudflare, modern hosting
- Connection infrastructure already available
- Check: proxy_read_timeout configured for long connections
Team comfortable with connections
- Experienced team, prior WebSocket projects
- Can handle reconnect logic, monitoring, edge cases

The gray area (100-1,000 users, 5-30s updates):

Either approach works. Context decides:

Polling if: Unsure of growth, want simplest solution, team is learning, infrastructure doesn't support WebSocket
Streaming if: Expect rapid growth (avoid migration later), team has experience, better UX is priority, infrastructure is ready

Can you migrate later? Yes. Start polling, migrate to streaming when you hit 3+ streaming criteria.

Migrating between polling and streaming

Polling → Streaming

When to migrate:

User base growing past 1,000 concurrent
Latency becoming a user complaint
Bandwidth costs exceeding $400/month
Rate limiting becoming an issue (> 80% of API quota used)

How I've done it:

Don't flip all users at once. Week 1: 10% of users to streaming (monitor errors, latency). Week 2: 50% of users (ensure infrastructure handles load). Week 3: 100% of users (keep polling code as fallback).

Use feature flags (LaunchDarkly, custom flag) to toggle streaming on/off per user segment. Instant rollback if issues arise. A/B test latency improvements. Gradual migration reduces risk.

Don't delete polling code. Use it during streaming outages (automatic graceful degradation). Some clients may have firewall/proxy issues with WebSocket. Fallback ensures service continuity.

Challenges I hit:

Different client code. Polling uses fetch(), streaming uses EventSource or WebSocket. Need separate code paths. Solution: abstraction layer that switches transport based on feature flag.

Connection monitoring needed. Track active connections, reconnect rates, message throughput. Solution: Add Prometheus metrics, Grafana dashboards before migration.

Reconnect storms. After outage, all clients reconnect simultaneously. Solution: Exponential backoff with jitter (randomize reconnect timing).

Timeframe: 2-4 weeks for production-ready streaming migration (code changes, testing, monitoring setup, gradual rollout).

Streaming → Polling fallback

When to fallback (temporary):

Streaming infrastructure repeatedly failing
Emergency mitigation during outage
Client environments blocking WebSocket (corporate proxies)

Keep polling code alongside streaming. Use feature flag to toggle. During streaming outage, automatically switch users to polling.

If EventSource errors exceed threshold (5 errors in 1 minute), fallback to polling for that user.

This isn't a permanent downgrade. It's graceful degradation. Streaming resumes when infrastructure recovers.

Hybrid approach

Can they coexist? Yes. I've seen streaming for power users (logged-in, active traders), polling for casual users (anonymous, checking prices occasionally).

Benefits: Optimize for each segment. Power users get best experience (streaming). Casual users don't require expensive infrastructure.

Complexity: Need to maintain both code paths. Only worth it if user segments are clearly distinct.

Crypto exchange example: streaming for logged-in traders (5,000 users), polling for anonymous price checkers (50,000 users). Saves infrastructure costs while delivering best experience to users who need it.

Production failures I've seen

Polling failures

Thundering herd (simultaneous polling)

All clients start polling at the same time (page load at midnight). Every 30 seconds, 10,000 requests hit within a 100ms window. Self-inflicted traffic spike overwhelms server.

One team told me: "We saw 12,000 requests hit within 200ms every 30s. Server CPU spiked to 95%, responses slowed to 5-8 seconds, causing more timeouts."

Solution: Add jitter to randomize polling interval by ±20%:

const baseInterval = 30000;
const jitter = Math.random() * 0.4 * baseInterval - 0.2 * baseInterval; // ±20%
const interval = baseInterval + jitter;
setInterval(pollPrices, interval);

This spreads 10,000 requests across a 12-second window instead of 200ms. Server load stays smooth.

Stale data during fast markets

Users see 30-second-old prices during high volatility. Bitcoin dumps 5%, user sees stale price, makes decision on outdated data, blames your app.

Feedback I heard: "During flash crash, our 30s polling showed prices 30s behind. Users lost trust. 'Your prices are wrong.'"

Solution: Show "Last updated X seconds ago" indicator. Transparency builds trust. Users understand data freshness.

Or reduce polling interval during detected volatility (price changes > 2% in 1 minute). Dynamic polling: 30s normally, 5s during volatility.

Rate limiting exhaustion

Frequent polling exhausts API quotas. Provider limits you to 100,000 requests/month. At 2,000 users with 30s polling, you hit 2.6 million requests/month (26× over limit).

One team: "We burned $1,000/month in overage charges before optimizing polling intervals and adding client-side caching."

Solutions:

Increase polling interval (30s → 60s cuts requests in half)
Add client-side caching (check cache before polling)
Server-side caching with short TTL (cache provider responses for 5-10s)

Streaming failures

Connection pooling limits

Load balancers have default connection limits (nginx: 1,024). At 1,000 streaming users, you're at 97% capacity. User 1,025 gets connection refused.

Production experience: "Hit nginx connection limit at 980 users. Next 200 connection attempts failed with 'connection refused.' Users saw blank dashboards."

Solution: Configure higher limits in load balancer:

# nginx.conf
worker_connections 10240; # Default: 1024

Add connection server pool: distribute connections across multiple servers (each handles 2,000-5,000 connections).

Monitor: Track active connections, alert at 80% capacity.

Silent disconnects (zombie connections)

Connection appears open (no error thrown) but no data flows. Network middlebox (firewall, proxy) silently drops idle connections after 60s. Client thinks it's connected, server thinks it's connected, but messages don't flow.

One team found: "5% of connections were zombies. Open but not receiving data. Users saw stale prices for 10+ minutes before manually refreshing."

Solution: Heartbeat pings every 30s:

// Server sends heartbeat
setInterval(() => {
  clients.forEach(client => client.send('ping'));
}, 30000);

// Client detects missing heartbeats, reconnects
let lastHeartbeat = Date.now();
eventSource.addEventListener('ping', () => {
  lastHeartbeat = Date.now();
});

setInterval(() => {
  if (Date.now() - lastHeartbeat > 45000) { // No heartbeat for 45s
    eventSource.close();
    reconnect();
  }
}, 10000);

Reconnect storms (post-outage avalanche)

Server goes down for 2 minutes. All 10,000 users disconnect. Server comes back up. All 10,000 users reconnect simultaneously. Server drowns in connection avalanche, goes down again. Repeat.

Production story: "After 5-minute outage, 8,000 users reconnected within 30 seconds. Connection server CPU hit 100%, crashed again. Took 45 minutes to stabilize."

Solution: Exponential backoff with jitter:

let reconnectDelay = 1000; // Start at 1s
const maxDelay = 60000; // Cap at 60s

function reconnect() {
  setTimeout(() => {
    // Add jitter: ±50% randomization
    const jitter = reconnectDelay * (Math.random() - 0.5);
    const delay = reconnectDelay + jitter;

    eventSource = new EventSource(url);
    reconnectDelay = Math.min(reconnectDelay * 2, maxDelay); // Double delay, cap at 60s
  }, reconnectDelay);
}

First reconnect attempts spread across 0.5-1.5s. If that fails, 1-3s. Then 2-6s, 4-12s, etc.

Result: "After implementing exponential backoff with jitter, post-outage reconnect storm dropped from 60% failure rate to 2%."

What to monitor

For polling:

Request latency (p50, p95, p99)
Rate limit headroom (requests used / requests available)
Cache hit rate (if using caching)
Error rate (failed polls / total polls)

For streaming:

Active connections (current / max capacity)
Reconnect rate (reconnects per minute)
Message throughput (messages sent per second)
Connection duration (how long connections stay alive)
Zombie connection rate (heartbeat timeouts / active connections)

Set up alerts:

Polling: Alert when rate limit > 80%, latency p95 > 2s
Streaming: Alert when connections > 80% capacity, reconnect rate > 100/min

What I learned

Neither polling nor streaming is universally better. Your context determines the right choice.

Polling works when updates > 30s acceptable, users < 100, standard hosting, team learning real-time systems.

Streaming works when updates < 5s required, users > 1,000, WebSocket infrastructure available, team experienced with connections.

Gray area exists: 100-1,000 users, 5-30s updates. Either works. Evaluate infrastructure, team skills, growth expectations.

Start simple. Begin with polling for MVPs and small user bases. Migrate to streaming when you hit 3+ streaming criteria (> 1,000 users, < 5s latency, WebSocket infra ready, team experienced).

Hybrid is valid. Use streaming for power users, polling for casual users. Optimize for each segment.

The decision isn't permanent. Architecture evolves as your app scales. Poll first, stream later is a proven path.

I work at CoinPaprika/DexPaprika, so the examples use our APIs. Polling examples use CoinPaprika's REST API. Streaming examples use DexPaprika's real-time feeds. Both completely free. No credit card, no rate limits, just start building.

Quick answers

Which is cheaper?

Depends on scale. At < 100 users, polling is cheaper ($30-50/month vs $75-100/month for streaming infrastructure). The crossover point is around 800-1,000 users. Above 1,000 users, streaming becomes significantly cheaper due to bandwidth efficiency.

Cost at 1,000 users: Polling = $400-500/month, Streaming = $150/month.

Which has lower latency?

Streaming has lower latency. Polling latency ranges from 0 to 1× your polling interval (30s polling = 0-30s stale data). Streaming delivers updates in < 1 second (typically 100-500ms). For detailed latency measurements, see What "Real-Time Crypto Prices" Actually Means.

Can I switch later?

Yes. Keep polling code as fallback, add streaming behind feature flag, roll out incrementally (10% → 50% → 100% of users). Timeframe: 2-4 weeks for production-ready migration.

When should I use each?

Polling: Updates > 30s acceptable, users < 100, standard hosting, team learning.

Streaming: Updates < 5s required, users > 1,000, WebSocket infrastructure available, team experienced.

Gray area (100-1,000 users, 5-30s updates): Either works. Start with polling, migrate to streaming when proven.

What infrastructure does streaming require?

Streaming requires WebSocket-capable load balancers (AWS ALB, GCP Load Balancing, Cloudflare), connection pooling configuration, and increased connection limits. Default nginx allows 1,024 connections. Configure higher for production. Polling works with any standard HTTP server.

What "Real-Time Crypto Prices" Actually Means - Understand latency, freshness, and guarantees
Server-Sent Events (SSE) Explained for Crypto Apps (Coming soon)
SSE vs WebSockets: Choosing the Right Transport (Coming soon)

What "real-time crypto prices" actually means (latency, freshness, and guarantees)

Mateusz Sroka — Thu, 15 Jan 2026 22:53:12 +0000

Last updated: January 2026

Quick heads up: I work at CoinPaprika/DexPaprika, so I'm using our APIs in these examples. But all the measurements are real - you can run the code yourself and verify everything.

I spent way too long debugging why my "real-time" price feed was showing stale data. Turned out my 5-second polling was giving me 10-second-old prices.

You see "real-time prices" everywhere. Crypto dashboards promise "live updates." APIs claim "instant data." But what does "real-time" actually mean when you're building applications that need crypto price data?

The answer: it depends. "Real-time" is a marketing term, not a technical specification. One API's "real-time" might deliver data every second. Another's might update every 10 seconds. Both call themselves "real-time."

In this article, you'll compare three different approaches to getting crypto prices - two using polling (REST APIs) and one using streaming (Server-Sent Events). You'll write Python code to measure actual latency and see the differences yourself. No theory. Just working code and real measurements.

You'll learn what latency, freshness, and guarantees actually mean, how polling differs from streaming, and how to measure any API's "real-time" claims. Plus why your 5-second poll interval gives you 10-second-old data.

We'll use three real APIs:

CoinPaprika REST - Centralized exchange data via polling
DexPaprika REST - DEX data via polling
DexPaprika Streaming - DEX data via Server-Sent Events

All code examples are fully functional, and the expected outputs shown use actual values from live API calls (BTC: ~$96,600, ETH: ~$3,300).

Three metrics that actually matter

You'll measure three things in this article:

Latency: Time from trade -> your app
Freshness: How old the data is when you receive it
Guarantees: What the API promises (if anything)

Here's what these mean with actual code and measurements.

Latency: time from event to delivery

Latency is the time between when a price changes and when that change reaches your application.

For example:

Trade happens on Ethereum at 10:00:00
Transaction confirmed in block at 10:00:12 (12 seconds - Ethereum block time)
API indexes the transaction at 10:00:13 (1 second - processing)
API sends update to your app at 10:00:13.5 (0.5 seconds - network)

Total latency: 13.5 seconds.

For DEX (decentralized exchange) prices on Ethereum, you cannot beat the ~12 second block time. It's a fundamental constraint. No API can deliver confirmed on-chain prices faster than the blockchain produces them.

CEX (centralized exchange) prices are different. Coinbase doesn't need to wait for blockchain confirmation - the trade happens in their database. CEX APIs can achieve sub-second latency.

Freshness: how old is your data?

Freshness is how old the data is when you receive it. It's what you can actually measure client-side.

Formula: freshness = now - trade_timestamp

If you receive a price at 10:00:20 and the trade happened at 10:00:08, your data is 12 seconds stale. That's your freshness.

For polling, freshness ≠ latency. With streaming, freshness approximately equals latency (you get updates as they arrive).

With polling, freshness = latency + average poll interval. If your poll interval is 5 seconds and the API has 1 second latency:

Best case: You poll right when new data arrives = 1-second freshness
Worst case: New data arrives right after you poll = 6 second freshness (1s latency + 5s until next poll)
Average: ~3.5 second freshness

Polling always adds latency because of the wait time between requests.

Guarantees: what can actually be promised?

Most APIs promise vague "real-time" delivery. Some actually guarantee numbers.

APIs can guarantee:

Update frequency ("new data every 1 second")
Uptime ("99.9% available")
Freshness window ("never > 5 seconds old")

APIs cannot guarantee:

Exact latency (networks vary)
Faster than blockchain (physics)
Zero message loss (connections fail)

Free APIs usually say "best effort." Paid tiers might guarantee "P95 < 2s." Enterprise SLAs add financial penalties.

Look for numbers, not marketing.

Polling approach: REST API requests on an interval

Polling is the traditional approach: make HTTP requests on a schedule.

How polling works

Loop forever:
  1. Make HTTP request
  2. Wait for response
  3. Process data
  4. Sleep for N seconds
  5. Repeat

Your poll interval determines maximum freshness. Poll every 5 seconds? Your data will be 5-10 seconds stale on average.

Trade-off: Faster polling = more requests = higher costs and potential rate limiting.

Example: CoinPaprika REST API for centralized exchange prices

CoinPaprika provides centralized exchange data via a REST API. Let's poll it every 5 seconds.

# coinpaprika_polling.py
"""Poll CoinPaprika REST API every 5 seconds"""

import requests
import time
import json

POLL_INTERVAL = 5  # seconds
DURATION = 30  # seconds
COIN_ID = "btc-bitcoin"
API_URL = f"https://api.coinpaprika.com/v1/tickers/{COIN_ID}"  # Public API, no auth required

def poll_coinpaprika():
    print(f"Polling CoinPaprika every {POLL_INTERVAL}s for {DURATION}s...\n")

    start_time = time.time()
    request_count = 0

    while time.time() - start_time < DURATION:
        try:
            response = requests.get(API_URL, timeout=10)
            response.raise_for_status()
            data = response.json()

            price = data['quotes']['USD']['price']
            last_updated = data['last_updated']

            request_count += 1
            print(f"[DATA] Request #{request_count}")
            print(f"  Price: ${price:,.2f}")
            print(f"  Last updated: {last_updated}")
            print(f"  Note: No trade timestamp - can't measure exact freshness\n")

        except requests.exceptions.RequestException as e:
            print(f"Error: {e}\n")

        time.sleep(POLL_INTERVAL)

    print(f"Completed {request_count} requests in {DURATION} seconds")
    print(f"Average: {DURATION / request_count:.1f}s between updates")

if __name__ == "__main__":
    poll_coinpaprika()

Run it:

pip install requests
python coinpaprika_polling.py

Expected output:

Polling CoinPaprika every 5s for 30s...

[DATA] Request #1
  Price: $96,662.93
  Last updated: 2026-01-15T17:30:27Z
  Note: No trade timestamp - can't measure exact freshness

[DATA] Request #2
  Price: $96,665.12
  Last updated: 2026-01-15T17:30:32Z
  Note: No trade timestamp - can't measure exact freshness

...
Completed 6 requests in 30 seconds
Average: 5.0s between updates

The API doesn't include the actual trade timestamp, only "last updated." Without the trade timestamp, you cannot verify freshness client-side. You have to trust the API.

Example: DexPaprika REST API for DEX prices

DexPaprika focuses on DEX (decentralized exchange) data. Let's poll it the same way.

# dexpaprika_polling.py
"""Poll DexPaprika REST API every 5 seconds"""

import requests
import time

POLL_INTERVAL = 5
DURATION = 30
CHAIN = "ethereum"
TOKEN_ADDRESS = "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2"  # WETH
API_URL = f"https://api.dexpaprika.com/networks/{CHAIN}/tokens/{TOKEN_ADDRESS}"  # Public API, no auth required

def poll_dexpaprika():
    print(f"Polling DexPaprika REST every {POLL_INTERVAL}s for {DURATION}s...\n")

    start_time = time.time()
    request_count = 0

    while time.time() - start_time < DURATION:
        try:
            response = requests.get(API_URL, timeout=10)
            response.raise_for_status()
            data = response.json()

            price = float(data['summary']['price_usd'])
            now = int(time.time())

            request_count += 1
            print(f"[DATA] Request #{request_count}")
            print(f"  Price: ${price:,.2f}")
            print(f"  Retrieved at: {now}")
            print(f"  Note: No timestamp in response\n")

        except Exception as e:
            print(f"Error: {e}\n")

        time.sleep(POLL_INTERVAL)

    print(f"Completed {request_count} requests")
    print(f"Freshness: ~{POLL_INTERVAL}-{POLL_INTERVAL * 2}s (estimated)")

if __name__ == "__main__":
    poll_dexpaprika()

Same pattern: request, wait, repeat. Same problem: no trade timestamp to verify freshness.

Polling characteristics and when to use it

Latency: API inherent latency (100ms-1s) + your poll interval (5s) = 5-6 seconds total freshness

Freshness range:

Best case: Poll right when data updates = ~1 second stale
Worst case: Data updates right after poll = ~6 seconds stale
Average: ~3.5 seconds stale

Guarantees: No live updates between polls. If price changes 3 times during your 5-second sleep, you only see the last value.

Trade-offs:

Simple (just HTTP requests, works everywhere)
Easy to implement (no connection management)
Wastes requests (polling when nothing changed)
Adds latency (poll interval delay)
Rate limits restrict how fast you can poll

When polling makes sense:

Updates needed infrequently (> 10 seconds)
Simple integration required
One-time data fetches (page load, not continuous)
Firewall blocks persistent connections

Streaming approach: Server-Sent Events for real-time updates

Streaming flips the model: instead of asking for updates, the server pushes them to you.

How Server-Sent Events works

SSE (Server-Sent Events) is a simple protocol for server-to-client streaming:

1. Client opens persistent HTTP connection
2. Server sends updates as they occur
3. Client receives events in real-time
4. Connection stays open (no request loop)
5. Browser auto-reconnects if connection drops

No polling loop. No wasted requests. Updates arrive when they're available.

Example: DexPaprika streaming API with SSE

DexPaprika offers free streaming via SSE. Let's connect and measure.

# dexpaprika_streaming.py
"""Connect to DexPaprika streaming API"""

import sseclient
import requests
import time
import json

DURATION = 30
CHAIN = "ethereum"
TOKEN_ADDRESS = "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2"  # WETH
STREAM_URL = f"https://streaming.dexpaprika.com/stream?method=t_p&chain={CHAIN}&address={TOKEN_ADDRESS}"

def stream_dexpaprika():
    print(f"Connecting to DexPaprika streaming...")
    print(f"Duration: {DURATION}s\n")

    start_time = time.time()
    update_count = 0

    try:
        response = requests.get(STREAM_URL, stream=True, timeout=60)
        client = sseclient.SSEClient(response)

        print("Connected! Receiving updates...\n")

        for event in client.events():
            if time.time() - start_time > DURATION:
                break

            # Filter for trade price events (named event: t_p)
            if event.event == 't_p':
                try:
                    data = json.loads(event.data)

                    # Use probe-verified schema
                    price = data['p']  # Price
                    trade_time = data['t_p']  # Trade timestamp
                    server_time = data['t']  # Server timestamp

                    server_latency = server_time - trade_time

                    update_count += 1
                    print(f"[DATA] Update #{update_count}")
                    print(f"  Price: ${price}")
                    print(f"  Server latency: {server_latency}s\n")

                except (json.JSONDecodeError, KeyError) as e:
                    print(f"Error: {e}\n")

    except requests.exceptions.RequestException as e:
        print(f"Connection error: {e}")

    elapsed = time.time() - start_time
    print(f"Received {update_count} updates in {elapsed:.1f}s")
    if update_count > 0:
        print(f"Average: {elapsed / update_count:.2f}s per update")

if __name__ == "__main__":
    stream_dexpaprika()

Run it:

pip install requests sseclient-py
python dexpaprika_streaming.py

Expected output:

Connecting to DexPaprika streaming...
Duration: 30s

Connected! Receiving updates...

[DATA] Update #1
  Price: $3326.51
  Server latency: 1s

[DATA] Update #2
  Price: $3326.47
  Server latency: 1s

[DATA] Update #3
  Price: $3326.52
  Server latency: 1s

...
Received 28 updates in 30.1s
Average: 1.07s per update

Updates arrive continuously, roughly every second. No poll interval. No waiting.

Measuring streaming data freshness

But how fresh is this data really? Let's measure both server latency and total freshness.

# streaming_freshness.py
"""Measure streaming data freshness"""

import sseclient
import requests
import time
import json

DURATION = 60
CHAIN = "ethereum"
TOKEN_ADDRESS = "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2"
STREAM_URL = f"https://streaming.dexpaprika.com/stream?method=t_p&chain={CHAIN}&address={TOKEN_ADDRESS}"

def measure_freshness():
    print(f"Measuring freshness for {DURATION}s...\n")

    start_time = time.time()
    server_latencies = []
    total_freshnesses = []

    try:
        response = requests.get(STREAM_URL, stream=True, timeout=120)
        client = sseclient.SSEClient(response)

        for event in client.events():
            if time.time() - start_time > DURATION:
                break

            if event.event == 't_p':
                try:
                    data = json.loads(event.data)
                    now = int(time.time())

                    trade_time = data['t_p']  # When trade occurred
                    server_time = data['t']   # When server sent
                    price = data['p']

                    server_latency = server_time - trade_time
                    total_freshness = now - trade_time

                    server_latencies.append(server_latency)
                    total_freshnesses.append(total_freshness)

                    print(f"[DATA] Price: ${price}")
                    print(f"  Server latency: {server_latency}s")
                    print(f"  Total freshness: {total_freshness}s")
                    print(f"  Network delay: {total_freshness - server_latency}s\n")

                except Exception as e:
                    print(f"Error: {e}\n")

    except Exception as e:
        print(f"Connection error: {e}")

    # Print statistics
    if server_latencies and total_freshnesses:
        print(f"\n{'='*50}")
        print("FRESHNESS STATISTICS")
        print(f"{'='*50}")
        print(f"\nServer Latency:")
        print(f"  Min: {min(server_latencies)}s")
        print(f"  Max: {max(server_latencies)}s")
        print(f"  Avg: {sum(server_latencies) / len(server_latencies):.2f}s")
        print(f"\nTotal Freshness:")
        print(f"  Min: {min(total_freshnesses)}s")
        print(f"  Max: {max(total_freshnesses)}s")
        print(f"  Avg: {sum(total_freshnesses) / len(total_freshnesses):.2f}s")

if __name__ == "__main__":
    measure_freshness()

Expected output:

Measuring freshness for 60s...

[DATA] Price: $3326.51
  Server latency: 1s
  Total freshness: 2s
  Network delay: 1s

[DATA] Price: $3326.47
  Server latency: 1s
  Total freshness: 1s
  Network delay: 0s

...

==================================================
FRESHNESS STATISTICS
==================================================

Server Latency:
  Min: 1s
  Max: 2s
  Avg: 1.05s

Total Freshness:
  Min: 1s
  Max: 3s
  Avg: 1.8s

Streaming gives consistent 1-2 second freshness. Server processing adds ~1s. Network adds 0-1s. Total: 1-2s from trade to your app.

Streaming characteristics and when to use it

Latency: ~1-2 seconds (measured above)

Freshness: Consistent 1-2 seconds (updates arrive without polling delay)

Guarantees: Updates every second (predictable frequency), but no guarantee of zero message loss

Trade-offs:

Lower freshness (1-2s vs 5-10s polling)
Efficient (no wasted requests)
Immediate updates when prices change
Requires persistent connection
More complex (connection management, reconnection)
Browser connection limits (6 per domain on HTTP/1.1)

When streaming makes sense:

Updates needed frequently (< 5 seconds)
Real-time user experience required
Monitoring multiple tokens
High-traffic applications (efficiency matters)

Polling vs streaming: direct performance comparison

Let's run both approaches side-by-side and compare results.

Side-by-side test

# compare_approaches.py
"""Compare polling vs streaming simultaneously"""

import threading
import requests
import sseclient
import time
import json

DURATION = 60
POLL_INTERVAL = 5
CHAIN = "ethereum"
TOKEN_ADDRESS = "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2"

REST_URL = f"https://api.dexpaprika.com/networks/{CHAIN}/tokens/{TOKEN_ADDRESS}"  # Public API, no auth
STREAM_URL = f"https://streaming.dexpaprika.com/stream?method=t_p&chain={CHAIN}&address={TOKEN_ADDRESS}"

poll_updates = []
stream_updates = []
lock = threading.Lock()

def polling_thread():
    start_time = time.time()
    while time.time() - start_time < DURATION:
        try:
            response = requests.get(REST_URL, timeout=10)
            data = response.json()
            price = float(data['summary']['price_usd'])

            with lock:
                poll_updates.append(int(time.time()))

            print(f"[POLL] ${price:,.2f}")
        except Exception as e:
            print(f"[POLL] Error: {e}")

        time.sleep(POLL_INTERVAL)

def streaming_thread():
    start_time = time.time()
    try:
        response = requests.get(STREAM_URL, stream=True, timeout=120)
        client = sseclient.SSEClient(response)

        for event in client.events():
            if time.time() - start_time > DURATION:
                break

            if event.event == 't_p':
                try:
                    data = json.loads(event.data)
                    price = data['p']

                    with lock:
                        stream_updates.append(int(time.time()))

                    print(f"[STREAM] ${price}")
                except Exception as e:
                    print(f"[STREAM] Error: {e}")
    except Exception as e:
        print(f"[STREAM] Connection error: {e}")

def compare_approaches():
    print(f"Comparing polling vs streaming for {DURATION}s...\n")

    poll_thread = threading.Thread(target=polling_thread)
    stream_thread = threading.Thread(target=streaming_thread)

    poll_thread.start()
    stream_thread.start()

    poll_thread.join()
    stream_thread.join()

    print(f"\n{'='*50}")
    print("COMPARISON RESULTS")
    print(f"{'='*50}")
    print(f"\nPolling:")
    print(f"  Total updates: {len(poll_updates)}")
    print(f"  Frequency: Every {POLL_INTERVAL}s")

    print(f"\nStreaming:")
    print(f"  Total updates: {len(stream_updates)}")

    if len(stream_updates) > 0 and len(poll_updates) > 0:
        print(f"\nStreaming received {len(stream_updates) / len(poll_updates):.1f}x more updates")

if __name__ == "__main__":
    compare_approaches()

Run it:

python compare_approaches.py

Expected output:

Comparing polling vs streaming for 60s...

[STREAM] $3326.51
[STREAM] $3326.47
[POLL] $3,326.47
[STREAM] $3326.52
[STREAM] $3326.48
[STREAM] $3326.50
[POLL] $3,326.51
...

==================================================
COMPARISON RESULTS
==================================================

Polling:
  Total updates: 12
  Frequency: Every 5s

Streaming:
  Total updates: 58

Streaming received 4.8x more updates

Metrics comparison table

Metric	Polling (5s interval)	Streaming (SSE)
Average Freshness	7-8 seconds	1-2 seconds
Update Frequency	Every 5 seconds	Every ~1 second
Missed Updates	High (only see changes every 5s)	Low (see all changes)
Requests/Minute	12 HTTP requests	1 connection
Bandwidth	~12KB/min	~5KB/min
Complexity	Simple (requests library)	Moderate (SSE client)
Rate Limit Impact	High (12 req/min)	Low (1 connection)

Decision: when to use each approach

Use polling (REST) when:

Updates needed infrequently (> 10 seconds)
Simple integration required (no connection management)
Firewall/proxy blocks persistent connections
Updating data once per page load (not continuous monitoring)
Examples: Portfolio summary page, daily price charts, historical data

Use streaming (SSE) when:

Updates needed frequently (< 5 seconds)
Real-time user experience required
Efficient resource usage matters (high-traffic app)
Monitoring multiple tokens simultaneously
Examples: Live price tickers, trading dashboards, price alerts

Measuring and monitoring API performance

How do you verify an API's "real-time" claims? Build a measurement tool.

Statistics dashboard with P50, P95, P99 percentiles

# measure_latency.py
"""Collect latency statistics (P50, P95, P99)"""

import sseclient
import requests
import time
import json
from collections import deque

DURATION = 120
CHAIN = "ethereum"
TOKEN_ADDRESS = "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2"
STREAM_URL = f"https://streaming.dexpaprika.com/stream?method=t_p&chain={CHAIN}&address={TOKEN_ADDRESS}"

class LatencyMonitor:
    def __init__(self, window_size=100):
        self.latencies = deque(maxlen=window_size)

    def add_measurement(self, latency):
        self.latencies.append(latency)

    def get_statistics(self):
        if not self.latencies:
            return None

        sorted_lat = sorted(self.latencies)
        n = len(sorted_lat)

        return {
            'count': n,
            'min': sorted_lat[0],
            'max': sorted_lat[-1],
            'p50': sorted_lat[int(n * 0.50)],
            'p95': sorted_lat[int(n * 0.95)],
            'p99': sorted_lat[int(n * 0.99)],
            'avg': sum(sorted_lat) / n
        }

def measure_latency():
    print(f"Measuring latency for {DURATION}s...\n")

    monitor = LatencyMonitor()
    start_time = time.time()
    sample_count = 0

    try:
        response = requests.get(STREAM_URL, stream=True, timeout=180)
        client = sseclient.SSEClient(response)

        for event in client.events():
            if time.time() - start_time > DURATION:
                break

            if event.event == 't_p':
                try:
                    data = json.loads(event.data)
                    now = int(time.time())
                    latency = now - data['t_p']

                    monitor.add_measurement(latency)
                    sample_count += 1

                    if sample_count % 10 == 0:
                        stats = monitor.get_statistics()
                        print(f"[DATA] Samples: {stats['count']:4d} | "
                              f"P50: {stats['p50']}s | "
                              f"P95: {stats['p95']}s | "
                              f"Avg: {stats['avg']:.2f}s")

                except Exception as e:
                    print(f"Error: {e}")

    except Exception as e:
        print(f"Connection error: {e}")

    print(f"\n{'='*60}")
    print("FINAL LATENCY STATISTICS")
    print(f"{'='*60}")

    final_stats = monitor.get_statistics()
    if final_stats:
        print(f"Total samples: {final_stats['count']}")
        print(f"\nPercentiles:")
        print(f"  P50 (median): {final_stats['p50']}s")
        print(f"  P95: {final_stats['p95']}s - 95% faster than this")
        print(f"  P99: {final_stats['p99']}s - 99% faster than this")
        print(f"\nRange:")
        print(f"  Min: {final_stats['min']}s")
        print(f"  Max: {final_stats['max']}s")
        print(f"  Average: {final_stats['avg']:.2f}s")

if __name__ == "__main__":
    measure_latency()

Expected output:

Measuring latency for 120s...

[DATA] Samples:   10 | P50: 1s | P95: 2s | Avg: 1.20s
[DATA] Samples:   20 | P50: 1s | P95: 2s | Avg: 1.35s
[DATA] Samples:   30 | P50: 1s | P95: 2s | Avg: 1.40s
...

============================================================
FINAL LATENCY STATISTICS
============================================================
Total samples: 120

Percentiles:
  P50 (median): 1s
  P95: 2s - 95% faster than this
  P99: 3s - 99% faster than this

Range:
  Min: 1s
  Max: 4s
  Average: 1.43s

Understanding percentiles for API performance

Why percentiles matter more than averages:

P50 (median): Half of updates are faster, half are slower
P95: 95% of updates are faster - this is typical user experience
P99: 99% of updates are faster - worst 1% experience

Example: Average is 1s, but P95 is 3s. Most users (95%) see 1-3s latency, not 1s. The average hides outliers.

Use P95 to understand real-world performance.

Evaluating API claims: red flags and green flags

How to verify "real-time" marketing:

Red flags:

"Zero latency" or "instant" (impossible - physics limits)
No specific numbers (vague "fast" claims)
No timestamps in responses (can't verify freshness)
Promises sub-second DEX prices (cannot beat 12s Ethereum blocks)

Green flags:

Specific numbers ("P95 < 2s", "1 second updates")
Timestamps included in every response
Public status page showing uptime
Documents failure modes and limitations

Action: Run your own measurements. Don't trust marketing—verify with code like the examples above.

What I learned measuring "real-time"

"Real-time" without numbers is marketing, not a spec. Always ask for P95 latency and update frequency.

Polling adds your poll interval to freshness. My 5-second polls gave 7-8 second old data. Streaming cut that to 1-2 seconds.

Blockchain sets the floor. No DEX API can beat Ethereum's 12-second blocks. Anyone promising faster is lying.

Run the code above on any API you're evaluating. Measure, don't trust.

Try it yourself:

pip install requests sseclient-py
python dexpaprika_streaming.py

Quick reference:

Use streaming when you need frequent updates (< 5s) and continuous monitoring. Use polling for simple integration and infrequent updates (> 10s).

Verify claims by running measurement tools, checking for timestamps in responses, and calculating P50/P95/P99 (not just average).

Resources:

Code examples coming to GitHub soon - follow me for updates or reach out if you need them immediately.

DEV Community: Mateusz Sroka

Scaling crypto price feeds from 1 token to 10,000: architecture patterns that work in production

The four scale transitions

1-10 tokens: direct connections work fine

10-100 tokens: multiplexed connections

100-1,000 tokens: server-side fan-out

1,000-10,000 tokens: distributed architecture

The cost comparison that matters

Managed solutions

Self-hosted with DexPaprika (FREE)

Migration patterns: scaling without downtime

From 10 to 100 tokens

From 100 to 1,000 tokens

From 1,000 to 10,000 tokens

Common failures at each scale

10 tokens: "It works on my machine"

100 tokens: "The reconnection storm"

1,000 tokens: "The memory leak"

10,000 tokens: "The cache stampede"

Performance benchmarks by scale

Implementation timeline

Real-world case study: scaling a DEX aggregator

The hidden complexity of multi-chain architectures

The DexPaprika advantage for scaling

Summary

FAQ

Related articles

How live price feeds fail in production (disconnects, backpressure, spikes)

Reconnection apocalypse

Nginx timeout trap

Memory leaks from unbounded buffers (and how they sneak up on you)

Mobile network hell

Corporate proxy blackholes

AWS API Gateway costs (they will surprise you)

When to stay up vs when to fail

Summary

Frequently asked questions

How do I test for reconnection storms before production?

What's a safe heartbeat interval that won't drain mobile batteries?

Should I always implement both SSE and WebSocket?

How do I detect which failure mode is happening in production?

When should I give up and fallback to polling?

Related articles

Why 1-second polling doesn't scale (and the architectures that do)

Polling starts cheap, then explodes

The math

Where the money goes

Where polling breaks

Limit 1: Browser connection cap

Limit 2: Rate limiting hell

Limit 3: Thundering herd on deploys

What works instead

SSE for simplicity

WebSocket for bidirectional needs

Hybrid approach (recommended pattern)

Migration path: from polling to streaming

First two weeks: Add streaming alongside polling

Week 3: Increase streaming to 50%

Week 4-5: 100% streaming, keep polling as fallback

Eventually: Remove polling code (or don't)

When polling still makes sense

Low frequency updates (> 30 seconds)

One-off requests

Internal tools

Testing and development

Decision framework: polling vs streaming

Real-world migration results

Free streaming changes everything

Summary

Frequently asked questions

At what point should I migrate from polling to streaming?

Can I mix polling and streaming in the same application?

What if streaming fails? Do I need a polling fallback?

How do I handle the migration without downtime?

Is SSE really free with DexPaprika? What's the catch?

Related articles

SSE vs WebSockets: choosing the right transport for market data

Understanding the core difference

When SSE makes more sense

Unidirectional price feeds