Secaucus, New Jersey is not an arbitrary address: the US equities exchanges and the consolidated feeds that carry their data are concentrated in northern New Jersey, so being there is what keeps Massive's own ingestion path short. The practical consequence for you is that where you run your code outweighs anything you can tune inside it.
Applies to
- Plans: all plans. Location affects latency, not entitlement.
- Endpoints: the REST API at api.massive.com and the WebSocket clusters at socket.massive.com.
- Asset classes: all.
What this means for your latency
What this means for your latency is that distance is the dominant term, and you cannot optimize around it:
| Where your service runs | What to expect |
|---|---|
| Northern New Jersey or New York metro | The shortest path available to you |
| Elsewhere in North America | Tens of milliseconds added, one way |
| Another continent | Well over a hundred milliseconds added, one way |
After geography, the next largest cause is your own read loop rather than the network. A client that parses in the thread that reads adds its parse time to every event, and under a burst that can grow into the same range as a transatlantic hop.
How to measure rather than estimate
Every event carries the exchange timestamp, so you can measure your real end-to-end delay instead of reasoning about hops. Subscribe to a busy channel, subtract each event's timestamp from your own arrival time, and report percentiles. Check your clock first: if any result is negative, your machine's clock differs from the exchange's by at least that much and every figure carries the same offset.
If you need facility-level detail
If you need facility-level detail, for colocation, a cross-connect or a private link, start a chat at massive.com/contact and say what you are trying to build. The specific facilities we occupy change as we add capacity, so a current answer from a person is worth more than a list in an article, and there may be an option that suits you better than matching our location.
If you see an error
Latency that grows steadily through a session is a slow consumer, not a network problem. It ends in a disconnect once the server-side buffer fills.
Latency that is stable but high is geography. Moving your service closer is the only fix.
