Richard Pryor Stoles a lot of Half Cents and Buys a Ferrari
Why Floats and Decimals as Money Make Illegal States Representable
You've heard that one before: never represent money with a float.
Floats are good for science because they can represent humongous numbers in small memory spaces. The trick? Because they use base 2 internally, they're approximations. For anything that requires precision, floats are a recipe for disaster.
And precision is, precisely, all that matters when it comes to money.
Given how often we use software to deal with money, I've always been shocked by the fact that no major programming languages has a built-in money type.
You would expect otherwise, right? I guess it has to do with the fact that, in most cases, money is always dealt in the same currency throughout a single application (the so called reporting currency).
But commerce is now e-commerce, and dollars aren't as globally relevant as they used to. Money software nowadays has to deal with many currencies, all while keeping up with the increasing volume and speed. And it all has to add up to the penny!
Implementing your system using a single reference currency is no longer a good idea.
This is why one of the most valuable questions I ask in interviews to potential payments engineers is: what is the best data structure to represent monetary values?
A few years ago, if a candidate said "not floats", that would've been enough.
But I don't think that's a sufficiently valid answer anymore.
I'm Alvaro Duran, and this is The Payments Engineer Playbook. You've probably watched tons of tutorials online on how to build software that moves money around. That helped you get the job. But now you're tasked with maintaining and scaling one of those systems, with down-to-the-penny exactness, and you're starved for resources on how to do it.
You're not alone. It happened to me as well.
Over the last ten years, I've worked as a software engineer in fintech companies of all sizes, and I've seen what worked and what didn't. I've been part of many conversations about the best tools, the best resources, the best patterns. But these conversations have always been behind doors.
And I thought "you know what? It's time we have this conversations in the open".
In The Payments Engineer Playbook, we investigate the technology that transfers money. All to help you become a smarter, more skillful and more successful payments engineer. And we do that by cutting off one sliver of it and extract tactics from it.
Today's article is about the best data structure to represent money. You may have opinions, but the reality is that only one data structure is consistently good and leaves no room for errors. Literally.
This article focuses on:
Why Money isn't part of your business logic
The two most common approaches to represent monetary values, from companies like Stripe, Modern Treasury, Moov Financial and TigerBeetle (they don't agree on this topic)
Which one is best; facts, not opinions
Enough intro, let's dive in.