Keeping Up With The Databases
Payments technology is improving fast, and it would be a shame if your customers abandoned you because you didn't pay attention to it.
Five minutes of downtime per year is a reasonable target to aim for if you want to build payments technology.
Last week, Stripe published a blog post in which they claimed their systems had achieved in 2023 99.999 percent uptime, or roughly 5 minutes of downtime throughout the whole year. This is now state-of-the-art in payments. Soon, it will become the norm.
Stripe’s database, built on top of the open-source database engine MongoDB, also helped them achieve zero downtime migrations. I remember vividly having to spend a whole weekend on a project for a top tier retail bank in the UK migrating their data to a new system.
A whole weekend. Can you imagine? Stripe apparently does this without you even noticing.
Draconian availability thresholds and imperceptible database changes are what’s actually innovative in payments technology. And it will turn boring sooner than you expect, but I’m guessing that whatever payment system you’re using is not going to keep up with such a pace.
Forget about AI; it's the small stuff that matters.
Welcome to Money In Transit, the newsletter bridging the gap between payments strategy and execution. I’m Alvaro Duran.
Today’s post is the fourth installment on a series I’ve called A Sketch of a Payment Systems Protocol. You can read the first, second and third installments for free.
Want to be notified when there’s a new post? Hit that subscribe button below.
The most intriguing part of all this is that Stripe is just shamelessly copying what worked for the tech giants a decade earlier.
But copying is probably an understatement, full of nuance. Everyone starts off running on relational databases these days, even when they’re probably not very well suited for payments. In Relational Databases Aren’t Paying Off in Payments, I wrote:
Relational databases are great because they enforce a bunch of guarantees over your data [...]. But none of these guarantees have anything to do with business concepts. […]. If you’re not careful, relational databases can accept double payments. They can open the door to race conditions that could even bankrupt your company.
Constraints are helpful, but only when they’re also meaningful to the business. But using relational databases means accepting that connecting the guarantees it provides with what the end product can benefit from is left as an exercise to the developer. While also requiring a lot of operational work to have them.
The problem, though, is that engineers choose which database to use when they start building payments technology. Right when they have the least information about how it’s going to be used. Whatever data choice they made, they get stuck with it.
But what if we could replace the engine mid-flight? What if we didn’t have to be hamstrung by a database decision made when engineers didn’t know better?
What if we could build payments so that, when we wanted to aim at 99.999 percent uptime, we just did it?
Persistence Ignorance
The answer is: of course we can.
What we need is to treat relational databases as if they were MongoDB. In fact, what we need is to pretend that data lives in the server’s memory, not in external hard drives.
And to figure out the piece of code that bridges such an illusion with our very real databases.
Such an approach is called persistence ignorance, and the goal is to remove any storage concern from the code that handles business logic.
This is the kind of separation that gets you real business outcomes. Upgrading, upscaling, decommissioning storage technology happens independent of any changes in how payments are supposed to be handled by the system.
It also gets you the opportunity to do what Stripe did. And keep up with the real challenge now that computers are really fast: how to process, store and retrieve data.
Agnostic Protocols
But it also gets you something else. It gets you software that can be used regardless of the database you choose.
Engineers are frequently slowed down by open source software that works almost the way they want to, except in fundamental aspects such as storage. They won’t tell you, but they are often forced to use libraries they don’t like, because they were forced to operate with “platforms” that narrowed their options to just a couple of bad choices.
Engineers should be able to use the best tool for the job. In whatever layer they’re working with.
That is why I’m building a payment orchestration library that is storage agnostic. As long as you’re using Python, one of the most widespread programming languages out there, you can use whatever database you want with it. No questions asked.
This is not only convenient, it is also helpful. It laser focuses optimization efforts on the same piece of software, rather than spreading those efforts into competing libraries. As a result, it helps surface the obvious and the not-so-obvious bugs.
And because performant code is the result of thousands of micro-optimizations, it helps everyone run their payments faster, on top of cheaper hardware, and achieving better availability numbers.
What Stripe did is a remarkable achievement. It shows it can be done.
Let’s not stay behind. Let’s build.