Normalize data before downstream systems consume it
Raw sources can differ in symbol names, decimal precision, timestamps and session behaviour. A normalization layer creates one internal instrument definition so trading servers, bridges, dashboards and risk services do not each solve the same mapping problem differently.
Price freshness is part of data quality
A feed can be connected and still be unusable. We define freshness thresholds, timestamp handling, missing-update detection and session-aware health checks so operators can distinguish a quiet market from a stalled source.
- Source and instrument inventory
- Symbol/precision/timestamp normalization
- Stale-price and update-rate checks
- Source selection or aggregation policy
- Consumer-isolated distribution
- Feed-health logs and failover tests
Distribution should isolate consumers
Trading platforms, bridges and internal services may consume the same normalized stream at different rates. Distribution architecture should prevent a slow or unavailable consumer from blocking other systems and should expose delivery errors separately from source-feed health.
Spread and source behaviour need explicit policy
Where multiple sources are involved, selection or aggregation rules should be documented. Outlier handling, source priority, spread calculations and failover criteria must be testable so a source change does not unexpectedly alter downstream pricing.
Monitor the full path, not just the socket
Production monitoring should cover source connectivity, update rate, timestamp lag, stale instruments, mapping errors and downstream delivery. Historical logs help determine whether an issue originated at the source, normalization layer or consumer.