Because a lot of the time there won’t be any error when you’re wrong, just silent data loss.
replyI’ve seen bugs like this in prod systems. The notional value of the error tends to make the people concerned anything but silent.
replyCustomer was charged $0.995 after fees, how to represent in your data model with integer cents?
replyYou'll have to decide when and how to round. Keeping individual billing items at high precision and rounding after summing them up can work; defining and documenting a rounding policy (or complying with whatever's legally required in your jurisdiction/domain) and rounding each individual billed item can as well.
replyCurrency: USD
Amount: 99500
Decimals: 5
replyYou use 1/1000th or 1/10000th or whatever you need. You do not need “cents”.
replyExactly, model is in integers and representation can be 1⃣3⃣ or whatever, that's why model-view separation exist.
replySure, you can do that if you can absolutely guarantee that everyone will always respect that separation and there will never be ambiguity between your internal and some partner's representation – even during incidents, even during low-level CSV-to-DB ETLs during incidents ("just one time, I promise, we don't have time to build the proper adapter, but look how similar their and our formats are").
replySure, but are all your (and your users' and vendors') engineers and LLM agents going to remember that? When in doubt, always be explicit.
replyI'm curious how you handle that.
replyLet's say I operate with a 4 decimal expectation and your API expects 6, is there any way to reconcile that outside of documentation and or metadata ? (which would be the same issue I guess whatever representation is used ?)
Yeah, you need to document it.
replyStill, even if you do: Chances that your users are just going to assume you're conforming to ISO 4217, some national standard, or your competitor that they're already integrated with are pretty high, so I wouldn't take the chance. Pick something that doesn't have to be documented instead.