Redundancy needs an explicit failover policy and evidence that the backup remains usable when the primary path fails.
Review whether connections share a source, network route, host or downstream gateway. Two sockets on the same dependency do not necessarily protect against that dependency failing; document the actual topology and remaining single points.
Check backup freshness and symbol coverage before switching. Test failback as well as failover, and decide how consumers handle a source change, a temporary gap and differences in price basis between providers.
Bring the proposed instrument list, source documentation and consumer workflow to a technical discussion. The agreed integration specification defines coverage, fields, usage permissions and acceptance tests.
| Input identity | Record approved sources, instrument definitions and symbol mappings. |
|---|---|
| Selection policy | Agree primary/backup, aggregation or distribution rules for each relevant consumer. |
| Health signals | Define freshness, source status, outlier handling and recovery thresholds. |
| Operational evidence | Retain policy versions, source changes and the reason for fallback or rejection. |
A production workflow for your instrument universe needs explicit rules for admitting, selecting and excluding inputs. Normalize definitions before comparing prices. A source that remains connected can still be stale for an individual instrument; expose that distinction in operations.