{"id":6743,"date":"2026-06-30T03:45:53","date_gmt":"2026-06-30T03:45:53","guid":{"rendered":"https:\/\/eodhd.com\/financial-academy\/?p=6743"},"modified":"2026-06-30T03:45:55","modified_gmt":"2026-06-30T03:45:55","slug":"real-time-market-data-reliability-stale-price-detection-rest-fallback-and-websocket-recovery","status":"publish","type":"post","link":"https:\/\/eodhd.com\/financial-academy\/fundamental-analysis-examples\/real-time-market-data-reliability-stale-price-detection-rest-fallback-and-websocket-recovery","title":{"rendered":"Real-Time Market Data Reliability: Stale Price Detection, REST Fallback, and WebSocket Recovery"},"content":{"rendered":"\n
\"Real-Time<\/figure>\n\n\n\n

A trading dashboard opens at market open. Prices are visible. No error appears. The WebSocket connection may still look connected. But one symbol has not received a fresh tick in 18 seconds.<\/p>\n\n\n\n

To the user, the quote still looks live. To the application, it may already be unsafe to trust.<\/p>\n\n\n\n

Missing data is easy to detect because something is clearly absent. Stale data is harder because the screen still has a price, the chart still has a last value, and the app may continue treating that value as current.<\/p>\n\n\n\n

A production market data layer needs to track more than the latest price. It needs to know where the price came from, when it was received, how old it is now, and what the application should do if the primary feed stops updating.<\/p>\n\n\n\n

A trading app should not only ask, \u201cDo I have a price?\u201d It should ask, \u201cHow fresh is this price, where did it come from, and am I allowed to trust it?\u201d<\/p>\n\n\n\n

This guide lays out the reliability model behind a recoverable market data layer: freshness checks, source labels, REST fallback rules, recovery states, and the operational table teams should expose before stale prices reach users. <\/p>\n\n\n\n

Real-Time Market Data Failure Modes in Trading Applications<\/strong><\/h2>\n\n\n\n

Real-time feeds fail in different ways. A closed WebSocket is only the obvious case. The harder failures happen when the connection is still open, the UI still has a number, and only part of the data has stopped being reliable.<\/p>\n\n\n\n

Failure Mode<\/th>What Happens<\/th>Why It Matters<\/th>Correct Response<\/th><\/tr><\/thead>
WebSocket disconnect<\/td>The connection closes or drops.<\/td>No new ticks arrive from the primary feed.<\/td>Reconnect and use fallback while the stream is unavailable.<\/td><\/tr>
Silent feed freeze<\/td>The connection stays open, but ticks stop arriving.<\/td>The app can keep showing an old price as if it were live.<\/td>Track quote age from the last trusted update.<\/td><\/tr>
Partial symbol starvation<\/td>Some symbols keep updating while others stop.<\/td>A connection-level health check can look fine while one symbol is stale.<\/td>Monitor freshness per symbol, not only per connection.<\/td><\/tr>
Delayed ticks<\/td>Messages arrive after a meaningful delay.<\/td>A tick can be new to the app but old relative to the market.<\/td>Compare exchange timestamp and receive timestamp.<\/td><\/tr>
Out-of-order ticks<\/td>An older tick arrives after a newer one.<\/td>The app can overwrite a fresher price with an older value.<\/td>Reject updates older than the last accepted timestamp.<\/td><\/tr>
REST fallback failure<\/td>The snapshot request times out or returns no usable price.<\/td>The app has no safe backup after the stream becomes stale.<\/td>Mark the symbol as DEAD, cached, or unavailable.<\/td><\/tr>
Market closed<\/td>No live ticks are expected.<\/td>A freshness check may incorrectly flag normal inactivity as failure.<\/td>Use session-aware logic and label the quote as market closed.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The common mistake is treating feed health as a connection problem. In production, market data health is usually a symbol-level problem. A WebSocket can stay connected while one ticker stops updating, one exchange sends delayed messages, or one fallback request fails.<\/p>\n\n\n\n

A recoverable market data layer needs to separate these cases. A disconnect, a stale quote, a delayed tick, and a closed market should not produce the same application behavior. Each one needs a different state, a different label, and a different next action.<\/p>\n\n\n\n

The next layer is the quote model. A price alone is not enough information to make that decision.<\/p>\n\n\n\n

Market Data Freshness Checks: What Every Quote Must Track<\/strong><\/h2>\n\n\n\n

A price value is only usable when the application also knows its source and age. Without that context, the same number can represent a fresh WebSocket tick, a REST snapshot, a cached value, or yesterday\u2019s close.<\/p>\n\n\n\n

Before any dashboard, alert, or trading rule uses a quote, the application should keep these fields attached to it.<\/p>\n\n\n\n

Field<\/th>Why It Matters<\/th><\/tr><\/thead>
Symbol<\/td>Identifies the instrument being tracked.<\/td><\/tr>
Price<\/td>Stores the latest usable value for the symbol.<\/td><\/tr>
Source<\/td>Separates WebSocket data, REST fallback, cached data, and previous-close values.<\/td><\/tr>
Exchange Timestamp<\/td>Shows when the market event happened at the exchange or data source.<\/td><\/tr>
Received Timestamp<\/td>Shows when the application received the update.<\/td><\/tr>
Age Seconds<\/td>Measures how old the latest trusted update is.<\/td><\/tr>
State<\/td>Labels the quote as live, degraded, stale, fallback, recovering, dead, or market closed.<\/td><\/tr>
Action<\/td>Tells the application whether to display, warn, reconnect, request fallback, or block.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Source labeling is what prevents fallback data from being mistaken for live data. Timestamp tracking is what prevents stale data from being mistaken for fresh data. State labeling connects both to application behavior.<\/p>\n\n\n\n

For example, a quote that came from the WebSocket feed two seconds ago can be displayed normally. A quote that came from a REST snapshot after the stream went stale can still be useful, but it should be labeled as fallback. A cached value from the last known price may be acceptable for a watchlist placeholder, but it should not trigger alerts or trading decisions.<\/p>\n\n\n\n

\"Market<\/figure>\n\n\n\n

This is the table the operations side of the application should see, even if the user interface shows a simpler status. It gives engineering, support, and product teams the same view of what the market data layer currently trusts.<\/p>\n\n\n\n

Market Data Recovery States: LIVE, STALE, FALLBACK, RECOVERING, and DEAD<\/strong><\/h2>\n\n\n\n

A real-time feed should not have only two states: connected or disconnected. That hides too much. A feed can be connected while one symbol is stale, a fallback snapshot can be available while the stream is down, and a reconnect can start before the stream is stable enough to trust again.<\/p>\n\n\n\n

A better model gives every quote a clear state.<\/p>\n\n\n\n

State<\/th>Meaning<\/th>Application Behavior<\/th><\/tr><\/thead>
LIVE<\/td>WebSocket updates are fresh.<\/td>Show the price normally.<\/td><\/tr>
DEGRADED<\/td>The latest update is getting old, but still within a usable window.<\/td>Keep displaying the quote, but monitor it closely.<\/td><\/tr>
STALE<\/td>The latest update is too old to trust as live.<\/td>Request a fallback snapshot.<\/td><\/tr>
FALLBACK<\/td>A REST snapshot is being used because the stream became stale.<\/td>Display the quote with a fallback label.<\/td><\/tr>
RECOVERING<\/td>WebSocket updates have resumed, but the stream is not confirmed yet.<\/td>Wait for multiple fresh ticks before returning to live.<\/td><\/tr>
DEAD<\/td>No reliable live or fallback price is available.<\/td>Block trading, suppress alerts, or mark the quote unavailable.<\/td><\/tr>
MARKET_CLOSED<\/td>Live ticks are not expected because the session is closed.<\/td>Show the latest valid session value with a market-closed label.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The thresholds depend on the product. A long-term portfolio dashboard may tolerate slower updates. A trading screen, alerting system, or intraday risk tool needs tighter freshness rules.<\/p>\n\n\n\n

A simple starting point could look like this:<\/p>\n\n\n\n

Condition<\/th>State<\/th><\/tr><\/thead>
Quote age is 3 seconds or less<\/td>LIVE<\/td><\/tr>
Quote age is above 3 seconds and up to 10 seconds<\/td>DEGRADED<\/td><\/tr>
Quote age is above 10 seconds<\/td>STALE<\/td><\/tr>
REST snapshot succeeds after a stale event<\/td>FALLBACK<\/td><\/tr>
WebSocket updates resume after fallback<\/td>RECOVERING<\/td><\/tr>
Three consecutive fresh WebSocket ticks arrive<\/td>LIVE<\/td><\/tr>
WebSocket data is stale and REST fallback fails<\/td>DEAD<\/td><\/tr>
Market session is closed<\/td>MARKET_CLOSED<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

These thresholds are not universal. They should be adjusted by exchange, asset class, update frequency, market session, and the consequence of showing a stale price. A delayed watchlist and a trade confirmation screen should not share the same tolerance.<\/p>\n\n\n\n

WebSocket Recovery and REST Fallback Architecture<\/strong><\/h2>\n\n\n\n

The primary feed should be the WebSocket stream. It gives the application the live updates needed for dashboards, alerts, and intraday views. The fallback path should stay separate so the application can keep showing usable data without pretending the stream is healthy.<\/p>\n\n\n\n

\"Real-Time<\/figure>\n\n\n\n

A practical recovery workflow looks like this:<\/p>\n\n\n\n

    \n
  1. Receive real-time ticks from the WebSocket feed.<\/li>\n\n\n\n
  2. Store the latest price, source, exchange timestamp, and received timestamp for each symbol.<\/li>\n\n\n\n
  3. Calculate quote age continuously.<\/li>\n\n\n\n
  4. Move symbols from LIVE<\/code> to DEGRADED<\/code> and then STALE<\/code> when updates slow down.<\/li>\n\n\n\n
  5. Request a REST<\/code> snapshot for stale symbols.<\/li>\n\n\n\n
  6. Mark successful snapshots as FALLBACK<\/code>.<\/li>\n\n\n\n
  7. Mark failed snapshots as DEAD<\/code>, cached, or unavailable.<\/li>\n\n\n\n
  8. Move symbols to RECOVERING<\/code> when WebSocket updates resume.<\/li>\n\n\n\n
  9. Return to LIVE<\/code> only after confirmed fresh ticks.<\/li>\n<\/ol>\n\n\n\n

    REST fallback is not a replacement for the live stream. It is a recovery layer. A fallback snapshot can keep a dashboard useful during a feed issue, but it should carry its own source label and timestamp. A user, alerting rule, or internal support tool should be able to tell the difference between a fresh WebSocket tick and a fallback REST<\/code> price.<\/p>\n\n\n\n

    Historical EOD prices have a different role. They are useful for previous-close context, market-closed displays, reference checks, and sanity checks. They should not be treated as live recovery data. If the application shows a previous close during a live-feed failure, the source should say previous_close<\/code>, cached, or market_closed<\/code>.<\/p>\n\n\n\n

    Where The Recovery Model Gets Stress-Tested<\/strong><\/h2>\n\n\n\n

    A full WebSocket disconnect is easy to reason about. The connection drops, ticks stop arriving, and the application starts reconnect and fallback logic.<\/p>\n\n\n\n

    The harder failures are quieter.<\/p>\n\n\n\n

    One symbol freezes while the feed stays connected<\/strong><\/h3>\n\n\n\n

    AAPL.US<\/code>, NVDA.US<\/code>, and TSLA.US<\/code> may keep updating while MSFT.US<\/code> stops receiving fresh ticks. A connection-level check can still look healthy, so the application has to track quote age per symbol.<\/p>\n\n\n\n

    Expected path:<\/p>\n\n\n\n

    LIVE -> DEGRADED -> STALE<\/code><\/p>\n\n\n\n

    The fallback path is unavailable<\/strong><\/h3>\n\n\n\n

    A stale quote may trigger a REST snapshot, but the request can timeout, return no usable price, or fail for that symbol. The state machine should not assume fallback always works.<\/p>\n\n\n\n

    Expected path:<\/p>\n\n\n\n

    STALE -> DEAD<\/code><\/p>\n\n\n\n

    The application can show a cached value if the product allows it, but the quote should not be treated as live.<\/p>\n\n\n\n

    Recovery is noisy<\/strong><\/h3>\n\n\n\n

    WebSocket ticks may resume briefly and then pause again. Moving a symbol straight from FALLBACK<\/code> to LIVE<\/code> after one tick can create false recovery.<\/p>\n\n\n\n

    Expected path:<\/p>\n\n\n\n

    FALLBACK -> RECOVERING -> LIVE<\/code><\/p>\n\n\n\n

    The symbol should return to LIVE<\/code> only after the configured number of fresh ticks arrives.<\/p>\n\n\n\n

    These cases expose the assumptions behind the workflow: freshness has to be symbol-level, fallback has to be labeled separately, and recovery has to be confirmed before the price is trusted again.<\/p>\n\n\n\n

    Python Example: Market Data Freshness, Fallback, And Health Table<\/strong><\/h2>\n\n\n\n

    The code does not need to build a full WebSocket client. The useful part is the state each symbol carries and the decision path when a quote becomes stale.<\/p>\n\n\n\n

    Exact Threshold Config\u00a0Changes<\/strong><\/h3>\n\n\n\n
    live_threshold_seconds = 3
    stale_threshold_seconds = 10
    recovery_ticks_required = 3<\/pre>\n\n\n\n
    These values should be visible because they define the application\u2019s latency budget. A portfolio dashboard may tolerate slower updates. A trading screen, intraday alert, or risk workflow may need tighter freshness rules. The recovery tick count controls how many fresh WebSocket updates are required before a symbol returns from RECOVERING<\/code> to LIVE<\/code>.<\/p>\n\n\n\n
    Define The Quote Store<\/strong><\/h3>\n\n\n\n
    Start with a small per-symbol store.<\/p>\n\n\n\n
    quote_store = {
        symbol: {
            'price': None,
            'source': None,
            'exchange_time': None,
            'received_time': None,
            'age_seconds': None,
            'state': 'DEAD',
            'action': 'waiting'
        }
        for symbol in watchlist
    }<\/pre>\n\n\n\n
    Each symbol has its own row because feed health is not only a connection-level problem. A WebSocket can stay open while one ticker stops updating. The application needs to know which quote is fresh, which one is stale, and which one is using fallback data.<\/p>\n\n\n\n
    Update Quotes From WebSocket Ticks<\/strong><\/h3>\n\n\n\n
    When a fresh WebSocket tick arrives, the application updates the price, source, and timestamps for that symbol.<\/p>\n\n\n\n
    quote = quote_store[symbol]

    quote['price'] = tick_price
    quote['source'] = 'websocket'
    quote['exchange_time'] = exchange_time
    quote['received_time'] = received_time
    quote['age_seconds'] = 0
    quote['state'] = 'LIVE'
    quote['action'] = 'display'<\/pre>\n\n\n\n
    This keeps the latest trusted WebSocket value separate from any fallback value that may be used later.<\/p>\n\n\n\n
    Classify Freshness And Trigger Fallback<\/strong><\/h3>\n\n\n\n
    The freshness check runs separately. It compares the current time with the latest trusted received timestamp.<\/p>\n\n\n\n
    quote = quote_store[symbol]
    age_seconds = (now - quote['received_time']).total_seconds()
    quote['age_seconds'] = age_seconds

    if age_seconds <= live_threshold_seconds:
        quote['state'] = 'LIVE'
        quote['action'] = 'display'
    elif age_seconds <= stale_threshold_seconds:
        quote['state'] = 'DEGRADED'
        quote['action'] = 'monitor'
    else:
        snapshot = fetch_rest_snapshot(symbol)

        if snapshot:
            quote['price'] = snapshot['price']
            quote['source'] = 'rest_fallback'
            quote['received_time'] = now
            quote['age_seconds'] = 0
            quote['state'] = 'FALLBACK'
            quote['action'] = 'display with fallback label'
        else:
            quote['state'] = 'DEAD'
            quote['action'] = 'block'<\/pre>\n\n\n\n
    The REST snapshot does not quietly replace the WebSocket price. It changes the source to rest_fallback<\/code> and moves the quote to FALLBACK<\/code>. That label lets the interface, alerting layer, and support team treat the value differently from a live tick.<\/p>\n\n\n\n
    Build The Market Data Health Table<\/strong><\/h3>\n\n\n\n
    The state store can then be turned into a health table.<\/p>\n\n\n\n
    health_table = pd.DataFrame.from_dict(quote_store, orient='index')
    health_table = health_table[
        ['price', 'source', 'age_seconds', 'state', 'action']
    ]<\/pre>\n\n\n\n
    A simple output might look like this:<\/p>\n\n\n\n
    Symbol<\/th>Price<\/th>Source<\/th>Age Seconds<\/th>State<\/th>Action<\/th><\/tr><\/thead>
    AAPL.US<\/td>203.14<\/td>websocket<\/td>1.2<\/td>LIVE<\/td>display<\/td><\/tr>
    MSFT.US<\/td>421.88<\/td>rest_fallback<\/td>0.0<\/td>FALLBACK<\/td>display with fallback label<\/td><\/tr>
    NVDA.US<\/td>142.50<\/td>websocket<\/td>66.1<\/td>DEAD<\/td>block<\/td><\/tr>
    TSLA.US<\/td>188.20<\/td>websocket<\/td>3.1<\/td>DEGRADED<\/td>monitor<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    This table makes the data layer inspectable. A stale symbol is no longer hidden behind a working connection, and fallback data is no longer mixed with live streaming data.<\/p>\n\n\n\n
    Example: How A Stale Quote Moves Through The Recovery Workflow<\/h2>\n\n\n\n
    At this point, the application has the pieces needed to handle a quiet market data failure:<\/p>\n\n\n\n
      \n
    • a per-symbol quote record<\/li>\n\n\n\n
    • source labels<\/li>\n\n\n\n
    • received timestamps<\/li>\n\n\n\n
    • quote age<\/li>\n\n\n\n
    • recovery states<\/li>\n\n\n\n
    • REST fallback<\/li>\n\n\n\n
    • a health table<\/li>\n<\/ul>\n\n\n\n
      Now assume the WebSocket connection remains open. AAPL.US<\/code>, NVDA.US<\/code>, and TSLA.US<\/code> keep receiving ticks. MSFT.US<\/code> stops updating.<\/p>\n\n\n\n
      Nothing obvious breaks. The app still has a price for MSFT.US<\/code>. The difference is that the quote age keeps increasing.<\/p>\n\n\n\n            
      \n                
      \n                    \n
      09:30:01 MSFT.US LIVE WebSocket tick received\n09:30:06 MSFT.US DEGRADED no tick for 4.2s\n09:30:12 MSFT.US STALE no tick for 10.5s\n09:30:13 MSFT.US FALLBACK REST snapshot used\n09:30:21 MSFT.US RECOVERING WebSocket updates resumed\n09:30:25 MSFT.US LIVE 3 fresh ticks confirmed<\/code><\/pre>\n\n                <\/div>\n                
      \n