An internal service must send 200 byte position updates between two processes on one box at 100k a second within a 5 microsecond budget. Compare JSON, protobuf and a fixed-layout binary struct on encode cost, decode cost and schema evolution, then state what you ship and what it needs.

An internal service must send 200 byte position updates between two processes on one box at 100k a second within a 5 microsecond budget. Compare JSON, protobuf and a fixed-layout binary struct on encode cost, decode cost and schema evolution, then state what you ship and what it needs.

Approach: Put a per-message cost on each format for encode and decode, then weigh that against what each one gives you the first time a field has to be added.

Ship the fixed layout binary struct over shared memory, since JSON costs 2 to 5 microseconds a message to encode and decode and consumes most of the budget alone, protobuf costs 200 to 500 nanoseconds with an allocation per message, and a fixed layout struct costs the memcpy alone at under 50 nanoseconds, leaving the budget to the transport. JSON also inflates 200 bytes to 500 or more, which sets the ring buffer size. Protobuf buys field level schema evolution and cross-language support, which earns its encode cost on a control plane and not on a 5 microsecond data path. The fixed struct gives up evolution, so it needs a version field in the header, a rule that fields are only ever appended, an explicit little-endian layout, and a static assert on the struct size and on each member offset so that a padding change fails the build rather than corrupting the wire.

Follow-up: How would you add a field to the fixed layout while both processes are running and cannot be restarted together?

Key concepts: encode cost, schema evolution, fixed layout, static assert.