Minor nit pick: some products, such as exchange-traded calendar spreads, have prices that can go negative and in fact don't have a lower limit on price.

When I was writing trading systems, it was a big headache to modify a system original designed only for equities to handle other asset types, especially those that could have negative prices.

Fun fun, that must have been quite the project! Price is so cross-cutting to such systems. When I added futures to my first system (>15 years ago), I had no idea about negative prices and had tons of sanity checks, including positive price checks.

Even in 2020, some popular trading platforms failed to handle when oil futures went negative! Opportunity for the prepared, I suppose.

EDIT: Oh and saw your follow-up -- we used 0 to represent "market" which is clearly broken in this scenario. Works fine for positive-only prices though :)

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.

Side note: if you're using IEEE-754 doubles (not a great choice for decimalized prices), use NaN to indicate no price, missing price, etc. instead of using an "impossible" value like -1.0. It's always possible the system will be expanded to some domain where -1.0 is valid, requiring lots of on-the-fly rewriting of live systems literally handling multiple billions of dollars per day.

Better yet, use proper algebraic data types.