Binary Serialization and Wire Formats
Why exchanges and low-latency systems send data as fixed-layout binary bytes instead of human-readable text formats like JSON, and what that tradeoff costs in flexibility.
Prerequisites: Latency vs Throughput
A price update needs to travel from an exchange's matching engine to thousands of trading systems, get parsed, and drive a decision, all within microseconds. If that update is sent as JSON — {"symbol": "AAPL", "price": 190.23, "size": 100} — the receiving program has to scan character by character, find field names by matching text, convert ASCII digits into a floating-point number, and allocate memory for strings, none of which a CPU does quickly. A binary wire format skips all of that: every field lives at a fixed, known byte offset, in its native machine representation (a 4-byte integer is genuinely 4 bytes of integer, not a string of ASCII digits), so "parsing" a message is often just reading raw bytes directly into a struct — no scanning, no text-to-number conversion, no memory allocation for strings.
The tradeoff is legibility and flexibility. JSON is self-describing — you can read a message with your eyes and understand it without any external documentation — and adding a new field is just adding a new key, which every version of every parser can safely ignore if it doesn't recognize it. A binary format's fixed-offset layout means both sides must agree, out of band, on an exact schema: which bytes mean what, in what order, at what offsets. Change the schema and every consumer needs updated parsing code, or it will silently misinterpret the new layout as if it were the old one — there's no self-describing structure to fall back on.
Worked example: the parsing cost gap
A feed handler processes 500,000 messages per second at peak. Parsing a JSON-encoded quote message — scanning text, matching field names, converting ASCII price digits to a float — takes roughly 800 nanoseconds per message on typical hardware. At 500,000 messages/second, that's seconds of CPU time consumed per second just parsing — 40% of a CPU core, before any actual trading logic runs. The equivalent binary message, with price and size at fixed offsets in native 4-byte integer form, parses in about 15 nanoseconds — largely a direct memory copy. At the same message rate that's seconds per second, roughly 53x less CPU spent parsing, freeing essentially the entire core for actual decision-making instead of text processing.
What this means in practice
Nearly every exchange's raw market-data and order-entry protocols (FIX/FAST, ITCH, proprietary binary formats) use fixed binary layouts for exactly this reason, reserving JSON and similar text formats for less time-critical uses — configuration, historical data APIs, human-facing tooling — where legibility and easy schema evolution matter more than shaving nanoseconds. Binary protocols also compress naturally: fixed-width integer fields are smaller on the wire than the same number written as ASCII digits, which matters when bandwidth, not just CPU, is a bottleneck.
Binary wire formats place fields at fixed byte offsets in native machine representation, letting a receiver read data directly into memory with no text scanning or conversion — often tens of times faster to parse than an equivalent JSON message, at the cost of requiring both sides to agree on an exact, versioned schema.
A binary format's efficiency depends entirely on both ends agreeing on the exact schema. Deploying a schema change to the sender without updating every consumer doesn't produce an error message the way a missing JSON key might — it silently misinterprets bytes as the wrong field, which can be far more dangerous than a parse failure.
Related concepts
Practice in interviews
Further reading
- Gregg, Systems Performance, ch. 10 (Network)