A few years ago I sat in a postmortem for an outage that cost us most of a business day of failed settlements. The root cause was not a bug in anything we had written. It was a distributed streaming platform we had adopted eighteen months earlier because it was, at the time, the obvious modern choice. Nobody on the team could fully explain its rebalancing behavior under partition failure. We had bought a problem we did not understand in exchange for a scale we did not need.
That afternoon crystallized something I now say out loud in architecture reviews: in fintech, the exciting technology is usually the wrong technology. I do not mean we should ossify. I mean the default should be proven, well-understood, quietly reliable tools, and anything newer has to earn its place against a genuinely high bar. This is not caution for its own sake. It is a considered bet about where risk actually lives when you move money for a living.
What Boring Actually Means
Boring is a compliment in my vocabulary, and it is easy to misread it as "old" or "unambitious." That is not what I mean. A boring technology is one whose failure modes are documented, whose operational quirks are known to more people than just its inventors, and whose behavior under stress you can predict without running the experiment in production. PostgreSQL is boring. So is a well-configured load balancer, a message queue that has been shipping since before the current team was hired, and a monolith that deploys in one step.
The useful framing I have borrowed and repeated for years is the idea of innovation tokens. You get a small number of them. Every genuinely novel piece of infrastructure you adopt spends one, because it comes with unknowns that will cost you attention later. Spend them on the thing that is actually your competitive edge, and buy everything else off the shelf in its most unremarkable form.
The question I ask a team proposing a new datastore is simple: when this fails at 2am, who on this team has seen it fail before, and do they know why? If the honest answer is nobody, we are not adopting it yet.
The Real Cost of Novelty
The seductive thing about new technology is that the demo always works. The cost never shows up in the evaluation phase. It shows up eleven months later, when you hit the edge case the documentation glossed over, and the GitHub issue describing your exact problem has fourteen thumbs-up and no answer. I have lived that specific disappointment more than once, and it is a uniquely lonely feeling to be the largest known deployment of a tool that is quietly failing.
There is a second, quieter cost. Novel systems fragment your team's knowledge. When you run five different databases because each was the trendy pick in its quarter, no single engineer holds the whole picture, and your on-call rotation becomes a lottery. A boring stack has the opposite property: the person paged at 3am has almost certainly seen this failure before, or can find someone three desks over who has. That shared muscle memory is worth more than any benchmark.
None of this means new tools are never worth it. It means the burden of proof sits with the new thing, and the accounting has to include the years of operational tax, not just the launch.
Postgres Until It Hurts
My default data layer for almost anything is a single relational database, and for most of my career that has meant PostgreSQL or SQL Server. The instinct to reach for a specialized store per workload is one I actively push back on. You want a queue? A relational table with row locking will carry you astonishingly far. You want full-text search? Postgres does that. You think you need a document store because your data is "unstructured"? A JSONB column will let you defer that decision by two years, by which point you will understand your access patterns well enough to make it properly.
Here is the kind of thing I mean. People reach for a dedicated queue product to hand out work to background processors, when the boring version fits in a few lines and inherits every transactional guarantee the database already gives you:
-- Claim the next payout job atomically, skipping rows
-- another worker already holds. Boring, transactional, correct.
UPDATE payout_jobs
SET status = 'processing',
locked_by = :worker_id,
locked_at = now()
WHERE id = (
SELECT id
FROM payout_jobs
WHERE status = 'pending'
AND run_after <= now()
ORDER BY run_after
FOR UPDATE SKIP LOCKED
LIMIT 1
)
RETURNING id, account_id, amount_cents;That pattern has quietly run reconciliation and payout workloads for me at a few hundred jobs a second, on hardware that cost less than the annual license of the dedicated queue we were told we needed. When it eventually does hurt, and sometimes it genuinely does, you will know precisely which part hurts and why. That clarity is the whole point.
The Microservices Detour I Regret
I inherited a platform once that had been split into roughly forty services by a team that had read the right blog posts and drawn the wrong conclusion. The company had maybe thirty engineers. A single customer-facing payment took seven network hops, each an opportunity for a timeout, and tracing a failed transaction meant correlating logs across half a dozen repositories with subtly different logging conventions. The architecture diagram looked impressive on a slide. It was miserable to operate.
We spent the better part of a year merging services back together. Not all the way to a monolith, but toward a handful of coarse-grained services aligned to real business boundaries: ledger, onboarding, and the customer-facing API. Latency dropped, incidents dropped, and new engineers became productive in days instead of weeks. The lesson was not that microservices are bad. It was that we had paid the distributed-systems tax for an organizational structure we did not have, chasing a scale we would not reach for years.
Distributed systems are a solution to a people problem more than a technical one. If you do not yet have the teams to justify the boundaries, the boundaries are pure cost.
Why Regulators Reward the Predictable
There is a dimension to this that pure software shops get to ignore and we do not. When an auditor asks how a particular balance was calculated, "the eventually consistent view converged after the stream reprocessed" is not an answer that ends the conversation. A boring, transactional, immutable ledger with a clear write path is not just easier to operate. It is easier to explain, and in a regulated business, explainability is a first-class requirement, not a nice-to-have.
I have watched teams adopt eventually-consistent architectures for balances and then spend enormous effort building reconciliation and compensation logic to paper over the gaps, effectively reinventing the transactional guarantees they threw away, only worse and less tested. If a customer's available balance can be briefly wrong, in payments that is not a caching nuance. It is a potential overdraft, a failed compliance check, or a regulatory finding.
Boring technology tends to have boring, well-understood consistency semantics. That alignment between what the database promises and what the regulator expects is not a coincidence you should give up lightly.
When Boring Is Genuinely the Wrong Call
I would be lying if I pretended the boring answer always wins, and I distrust anyone who preaches a rule with no exceptions. The whole point of hoarding innovation tokens is to spend them deliberately on the things that are actually your edge. There are places where reaching for the newer, sharper tool is exactly right:
- When the capability is your actual differentiator. If real-time fraud scoring is what your customers pay for, that is precisely where specialized infrastructure earns its keep.
- When the boring option has a hard, proven ceiling you are demonstrably about to hit, with real numbers, not a hypothetical from a conference talk.
- When the newer tool is boring somewhere else. A technology can be novel to your team but battle-tested across the industry; that is a much safer bet than something genuinely unproven everywhere.
- When the operational cost of the old thing has quietly grown larger than the cost of learning the new thing. Boring can curdle into legacy, and pretending otherwise is its own failure.
The discipline is not "never adopt anything." It is refusing to spend a token on a problem you do not have, so you still have one left when a problem you do have shows up.
The Cultural Work Nobody Mentions
The hardest part of championing boring technology is not technical. It is that it can read as a lack of ambition to a room full of talented engineers who want to work on interesting problems, and who are, quite reasonably, thinking about their next role and the résumé it needs. That tension is real, and dismissing it is how you lose good people.
My answer is to relocate the ambition. The interesting problem in fintech is almost never the datastore. It is the ledger design, the fraud logic, the settlement timing, the developer experience of your API, the sub-second correctness of a reconciliation run at month-end close. I would rather my best engineers spend their curiosity there than on operating a fashionable database. Boring infrastructure is what buys them the room to do the genuinely hard work, without an incident eating their week.
How I Actually Decide
In practice the decision comes down to a short, unglamorous conversation. What problem are we actually solving, and is it real today or projected? What does the boring option cost us, honestly, including the ugly parts? What does the exciting option cost when it fails, and who here has felt that failure before? If the boring option merely embarrasses us and the exciting one can lose money or lose an audit, that asymmetry decides it.
I keep coming back to a phrase a mentor gave me early on: choose technology you can afford to be bored by. In a domain where the downside of a surprise is a regulator's phone call, boredom is not the absence of engineering excellence. It is one of its higher forms.
Conclusion
If there is one thing I would leave a younger version of myself with, it is this: the most impressive engineering decision I have ever made looked, from the outside, like refusing to make one. We did not adopt the streaming platform the second time it was proposed. We put the money in the ledger instead. Two years later the competitor who did adopt it was still fighting their infrastructure while we were shipping features. Nobody wrote a conference talk about our restraint, and that silence was exactly the win. Boring compounds quietly, and in fintech, quiet is the sound of a system you can trust.