Rust Market Data Normalization Starts at the Boundary

Market-data infrastructure becomes fragile when every downstream component learns a different venue dialect. One feed calls it a trade condition, another calls it a flag. One stream uses exchange timestamps, another carries receive time, and a third mixes precision into strings. The result is a strategy layer that knows too much about vendors.

A market-data normalizer should move that complexity to the boundary.

The canonical event

The useful abstraction is a canonical event envelope with explicit semantics:

• Venue and symbol identity.
• Exchange timestamp and receive timestamp.
• Lossless price and size representation.
• Event type and side semantics.
• Quality and tradability state.
• Replay-friendly ordering information.

This does not make vendor differences disappear. It makes them visible in one place, before they leak into ranking, risk, or replay.

Why Rust fits the job

Market-data normalization is latency-sensitive, allocation-sensitive, and correctness-sensitive. Rust is a practical fit because it lets the boundary be strict without giving up throughput. Types can carry venue identity, numeric precision can stay explicit, and sinks can be designed around predictable memory behavior.

FerroFeed is built around that idea: connectors come in at the edge, canonical events come out, and downstream systems inherit one schema instead of a vendor translation problem.

What this protects

The normalizer is not just plumbing. It protects every component that consumes market state: matching simulations, spread ranking, volatility surfaces, strategy replay, and operational monitoring. If data quality is bad, stale, or not tradable, that should be stated before the model sees the event.

The first correctness gate in a trading system is the boundary where external data becomes internal state.