Skip to content

// Industry

Market feeds that reconnect without their symbols

A feed that comes back connected and not subscribed. The socket is healthy, the dashboard is green, and the price on the screen stopped moving twenty minutes ago.

Start with a Sprint

// The problem

Why this is hard

A live feed does not fail loudly. It reconnects. The socket reports connected, every dashboard stays green, and the thing that actually broke — a symbol that never resubscribed, a gap the protocol offered to replay and nobody claimed — produces no error anywhere, because none of it is a request. What reaches the customer is a number that renders exactly as it did when it was true. The interesting part is that almost none of this is a bug in the reconnect logic: the transport layer usually recovers perfectly, and the application layer was never asked to.

  • The transport came back, the subscription did not

    A reconnected socket is a new socket, and room membership belonged to the one that left. Unless something re-issues the subscribe on connect, the client is attached to a feed that will never send it anything again.

  • The stream offers to resume and nobody asks

    Server-sent events carry an id field precisely so a client can say where it stopped, and the reconnect hint decides how often it has to. Send neither and every reconnect is an unrecoverable hole, sized by how long the gap lasted rather than by what was missed.

  • A heartbeat that only speaks

    A keepalive the server sends and nobody answers proves the socket can still be written to, which is not the question. A half-open connection accepts writes for as long as the operating system is willing to retry them, which on Linux defaults is at least a quarter of an hour.

// What matters here

The capabilities that move the needle

Real-Time Ops

Alerting on the counter that binds — for a feed, the age of the last tick per symbol, which is a different question from whether the connection carrying it is open.

Voice Agents in Production

Alerts that speak, and the desk phone that still carries the escalation — the other real-time surface in a trading product, and the one where being late is being wrong.

RAG & Knowledge Systems

Answers grounded in sources retrieved when the question was asked, checked claim by claim — because a summary of the market is a claim about the present tense.

// Deep dives

Going deeper for fintech

// Proof

Measured on our own hardware

resubscribe, 2 of 3 outages

0% → 100%

Probability a symbol update arrives within five seconds of the client reporting connected: nil for a client that subscribes once, certain for one that re-subscribes on connect — across a transport close and a three-second server restart, 40 trials per arm on our own harness. On the third mechanism both score nil, because that client never reconnects.

events lost per 2 s reconnect

100.6 → 0

Events a client missed on each reconnect with a two-second retry hint and one event every 20 ms: 100.6 with no id field, against the 100 that gap over cadence predicts — and none once every event is numbered and the server can still resume from the id the client held. Medians of three 30-second runs on our own harness, one process on loopback with no proxy and no TLS, so each figure is a floor.

erased after a silent drop

100%

How often a cleanup erased the registration of a client that had already reconnected and re-registered: never when the old connection closed or was reset, every time when it vanished silently and its stale handler fired afterwards, and never once the delete checks identity rather than key. Six trials per arm, the client back 150 ms after the cut, heartbeat timers about fortyfold faster than a real deployment's — certain inside the ping timeout, 67% one interval past it, gone beyond.

Not a client outcome and not a vendor figure — numbers we took, on hardware we can name, with the method published in full. The write-up: The socket reconnected. The subscription did not..

// FAQ

Common questions

Because every signal on that dashboard describes the connection, and the connection is fine. A symbol that never resubscribed sends no error and makes no request, the socket stays up, and the price keeps rendering exactly as it did when it was last true. What catches it is a question asked per symbol — how long since this one last ticked, against how often it normally does — and it is rarely on a dashboard, because it has to be computed from the data rather than read off the transport.

It covers the transport, which is usually the part that was never broken. Reconnection restores a socket; it does not restore what that socket was subscribed to, because the server sees a new connection with no memory of the old one's state. Whether your symbols come back depends entirely on whether your own code re-issues them on connect — one handler, and its absence is invisible until a customer notices a price that has not moved.

Nothing from production. A capture of a session, the reconnect and resubscribe path from your client, and your monitoring configuration are enough to reproduce the behaviour on our own replica and run the harness against your client's logic. No credentials, no market-data entitlement, no subscriber record, no customer information — which also means there is nothing here that changes what you owe your data vendor.

On a harness we built and ran ourselves: the real socket.io and socket.io-client 4.8.1 packages at their default reconnection settings, three outage mechanisms, and 40 trials for each client on each mechanism. Each mechanism is reported on its own and never averaged into one number, because on one of them even the correct client never reconnects. The results table and the method are published in the article the figure links to. None of it is anyone's production data — no trading volumes, no incident, no customer.

// Related

Related industries

All industries

// Let's build

Building AI for fintech?

Tell us where you are. We reply within a day with a concrete next step.