Field names travel in every MessagePack or CBOR record; when do you accept that permanent cost rather than move the fleet to a schema?

## The trade being made A self-describing binary encoding is one point on a line. On one side sits a text encoding: fully self-contained, human-readable, largest on the wire. On the other sits a schema-driven encoding: the smallest records, because field identity is reduced to a number both ends already agree on, at the price that a record is meaningless without the matching declaration. The schemaless binary family sits deliberately in the middle: **binary cost, self-contained semantics**. The question a lead actually owns is not "which is smaller" but **who has to agree on what, and when**. ## The case for staying self-describing - **No coordinated rollout.** A producer can start emitting a new field today. No declaration has to reach every consumer first, and no consumer has to be rebuilt to keep reading what it already understood. - **Records survive their producers.** A frame archived years ago, from firmware that no longer exists, still decodes. Nothing has to be kept alongside it. - **Generic tooling works.** One decoder renders any record for triage, without knowing your fields. That tool cannot exist for a schema-driven pipeline unless the declaration travels too. - **Partial fleets are normal, not exceptional.** With devices that wake rarely, are powered by batteries and may miss updates for months, "every producer upgraded" is a state you may never reach. An encoding whose correctness depends on reaching it is the wrong encoding. ## The case for moving to a declared contract - **Key bytes dominate at volume.** When records are small and numerous, the repeated names can be a large share of every frame — and on a metered link that is money and battery, every day, forever. - **You want evolution checked by a machine.** A declaration lets a tool say "this change breaks readers" before the change ships. Self-describing bytes let anything through and fail at the consumer. - **Producers and consumers are few and deployable.** If a handful of services all deploy from one pipeline, the coordination cost that makes schemas painful on a fleet largely disappears. - **Cross-language contracts and generated readers** are worth more to you than generic tooling. ## How to decide | Signal | Points to self-describing binary | Points to a declared contract | |---|---|---| | Can every producer be upgraded on your schedule? | no | yes | | Record lifetime | years, archived, replayed | short, in-flight only | | Number of distinct producers | large, heterogeneous, in the field | small, centrally deployed | | Share of bytes spent on key names | tolerable | dominant | | Need for machine-checked evolution | low | high | | Value of a generic decoder for triage | high | low | The honest principal answer names the **middle options** rather than treating this as binary. Batch many records and compress the batch: repeated key names are the most compressible thing in the payload, and a dictionary-based compressor removes nearly all of that redundancy, which can defer a schema migration for years. Shorten the key names themselves at the producer — unlovely, but it is a one-line change with no coordination cost. Or split the traffic: keep the long tail of diagnostic records self-describing, and move only the one high-volume record type onto a declared contract, so you pay coordination cost exactly where the bytes are. ## What makes this a judgment call rather than a calculation Both costs are real but they are paid by different people at different times. The key-name overhead is paid continuously, by the operating budget, in small amounts. The coordination cost of a declared contract is paid in lumps, by engineering, at the worst moments — during a rollout, during an incident, when an old device comes back online with a version nobody remembers. A lead who has run a fleet weights the second more heavily than a spreadsheet does, and says so. ## The trap to avoid Do not adopt a self-describing binary encoding **as if** it were a contract. It is not one: nothing in the bytes says a field is required, what it means, or that its meaning has not changed. If your reason for choosing it is "we do not want to maintain a declaration", you have not removed the contract, only the place it was written down — and it now lives in your consumers' assumptions, unversioned and unchecked. Choosing this family well means being explicit that the contract is documented and enforced elsewhere.