There are all kinds of problems with optionality not being properly represented in the data. At a C level, you really want a tagged union, and preferably you'r

There are all kinds of problems with optionality not being properly represented in the data. At a C level, you really want a tagged union, and preferably you're using a higher level language that has first-class algebraic data types (which end up looking just like tagged unions, tagged pointers, or NaN-boxed values at the hardware level). We had one bespoke protocol for communicating between the order management system (conceptually a high-reliability database that holds order state and communicates with components connected to exchanges) and the trading engines (higher code churn rate, and can recover order state from the order management systems if they need to be restarted, so less critical). When we created a second version of the order management system, we created a wholly new bespoke messaging protocol where every field was optional with a default value, and had an unfortunate feature that if one side set a field in a message to the default for that data type, the messaging layer would size-optimize the messages by removing that field. Combined with encoding order amendments as messages where all of the unchanged fields were removed, it meant that if an order ever had a field amended to a default value, the other side of the communication would interpret it as no change, and would acknowledge the message but not amend the value. It wasn't a big deal for a lot of the order paremeters that got thrown into a single customization string, since it probably wasn't actually possible to amend on order to become completely vanilla (upstream systems tacked on some customizations between receiving the order from the customer and presenting the order to the OMS). However, amending a price to zero would result in this space-saving optimization, and the trading engine would interpret it as no change in price. The API did have separate calls for getting a field value (which would transparently return the default value for missing fields) and for checking if a value was actually specified. Though, due to the "optimization" in the messaging layer, checking of a value was specified was really just a check if the returned value was equal to the default value.