How do you decide whether a Go service carries money as int64 minor units or float64?

## Frame it as an ownership question, not a type preference Every engineer can recite that floats are inexact. That is not the decision. The decision is: **what does this service promise about a monetary quantity, to whom, and who is accountable when the promise and another system's promise disagree by one cent?** Once framed that way, the type falls out of the contract rather than the other way round. ## The default, and why Carry money as an integer count of minor units — `int64` cents — with the scale recorded explicitly rather than assumed. Reasons, in the order they actually bite: - **Addition and equality are exact.** Summing a million rows introduces no residual, and `a == b` means the amounts are the same amount. With `float64`, both statements need a tolerance, and the tolerance becomes a parameter somebody has to defend. - **Reconciliation is possible at all.** A ledger compared against a bank's or a payment processor's ledger must match exactly. A tolerance-based match is a policy decision with a fraud surface, not an implementation detail. - **Range is a non-issue.** `int64` holds about 9.2 quintillion minor units; even at two decimals that is far past any plausible total. `float64` loses integer exactness above 2^53, which real aggregate columns can reach in minor units. - **The rounding conversation happens once.** With integers, rounding only occurs where you divide — tax, splits, interest — and each of those is a place where somebody must state a rule anyway. `float64` is the right answer for quantities nobody reconciles: an exchange rate, a projection, a dashboard series, a machine-learning feature. Saying so explicitly is part of the judgment — blanket bans produce awkward code where a rate becomes an integer with an invented scale. ## The parts that are somebody else's call I make the internal representation call. These I propose and get signed off, because they are visible outside the service and expensive to change: - **The scale in the exported schema.** Two decimals is not universal: some currencies have no minor unit and some have three. A field hardcoded to hundredths is a bug for a subset of the world, and the correct model carries the amount, the currency, and the exponent it is scaled by. - **The wire type.** A JSON number is convenient and dangerous: many decoders parse it straight into a 64-bit float, so an integer number of minor units is safe only while it stays under 2^53, and a decimal number is not safe at all. A decimal *string*, or an integer minor-unit field plus a currency field, survives any consumer. That choice belongs to whoever owns the API contract. - **The rounding rule and its single location.** Half-up, half-even, or always-toward-the-payer are business rules with regulatory weight in some domains, and rounding must happen once, at a named boundary, on a value that then becomes authoritative. Rounding in two places, or rounding on output while keeping a full-precision value in memory, produces two defensible totals for the same thing. - **What totals mean.** The sum of rounded parts and the rounded sum are different numbers. Which one the report shows is a business answer. ## The migration cost is why this is decided early Changing a monetary field's type or scale after consumers exist is not a refactor. It is: add the new field, dual-write both, migrate consumers one at a time, backfill history, reconcile the old and new columns over a full reporting period, then remove the old field. Months of calendar time and a reconciliation report nobody wanted to own. Pricing that out during design is what converts "floats are probably fine for now" into a decision somebody is willing to be wrong about in writing. ## What Go gives you, and what it does not The standard library has no decimal type. It offers `int64` arithmetic, and `math/big` — whose rational type does exact decimal arithmetic and can render a fixed number of decimal places, and whose arbitrary-precision float can be given an explicit precision. Both are heavier than integers and neither is a drop-in money type. In practice the shape that works is a small internal type wrapping an `int64` of minor units together with its currency, with parsing and formatting concentrated in one file so the rounding rule has exactly one home. Formatting for display is then integer division and a `%02d`-style pad, not a float verb. ## How I would present the decision One page: what the field means, whether anything reconciles it, the proposed internal representation, the proposed wire representation with its scale, where rounding happens, the migration cost if we are wrong, and the one question for the reviewer — typically "is any consumer going to sum these in a spreadsheet or a JavaScript client?", because the answer decides the wire type on its own. If the finance-data owner overrules the scale or the API reviewer insists on a string, that is the process working; the expensive failure is shipping the representation without ever having named it.