There's a lot of noise right now about microservices being overrated. The pattern is familiar: a team of five engineers adopts a Netflix-style architecture for an app with a hundred users, drowns in distributed-systems complexity they didn't need, writes a blog post about it, and the internet nods along. Martin Fowler wrote about this years ago in "MonolithFirst." DHH has spent a decade evangelizing the "majestic monolith." And honestly, they're not wrong — for most teams, most of the time.
But "most teams, most of the time" is doing a lot of work in that sentence. Fintech isn't most teams, and moving money isn't most problems. And once you've spent real time building systems where a bug means a transaction fails, a reconciliation breaks, or a regulator asks questions, the monolith-vs-microservices debate looks different.
The legitimate case against microservices
Let's give the critics their due, because the criticism isn't baseless:
- Operational overhead is real. Ten services means ten deployment pipelines, ten sets of logs to correlate, and a distributed tracing setup you now have to maintain.
- Small teams don't have the headcount. If you have four engineers, you don't have four teams — you have four people context-switching across services that used to be one codebase.
- Distributed transactions are genuinely harder. Sagas and eventual consistency are real complexity taxes that a single database transaction doesn't charge you.
- A lot of microservice adoption is cargo culting. Plenty of teams split things up because it's what "good" companies do, not because their system actually needed it.
If your product is a to-do app or an internal admin tool, I'd tell you to stay monolithic too. That's not the argument.
Why fintech breaks the calculus
Fintech systems have a property most software doesn't: a failure in one part of the system has a blast radius measured in money, not just inconvenience.
I've built and maintained payment infrastructure — settlement engines, interbank transfer integrations, mobile money collections across multiple African markets, direct debit automation. Across all of it, the pattern that mattered most wasn't code elegance. It was containment.
Here's a concrete version of the argument, not an abstract one: when I built out a Bills Payment service that integrated with a third-party vendor, that vendor's downtime or slow responses were entirely their problem — contained to one service, one failure domain. Merchants could still move money, check balances, and process transfers without ever noticing the bills vendor was having a bad day. If that same integration had been a module inside one big application process, a hung third-party call or a memory leak in that code path risks taking transfers and everything else down with it. In a modular monolith, you can try to isolate that with timeouts, circuit breakers, and careful thread management — but you're fighting the architecture, not being helped by it. In a microservice, isolation is the default, not something you have to engineer around.
That difference compounds across a few dimensions that matter specifically in fintech:
1. Independent failure domains aren't optional — they're regulatory. When your settlement engine, KYC service, and interbank transfer rails are separate deployables, an incident in one doesn't become an incident in all three. In an industry where downtime gets reported to regulators and customers lose real money during outages, "the whole platform is down because one dependency hiccupped" is not an acceptable failure mode.
2. Transaction volume is wildly asymmetric across services. A settlement engine processing thousands of merchant transactions has completely different scaling needs than a KYC upgrade service or an admin dashboard. Microservices let you scale the hot path independently instead of scaling your entire monolith (including the parts that don't need it) just to keep one component alive under load.
3. Compliance boundaries map naturally to service boundaries. PCI-DSS scope, NDPA data-handling rules, and audit requirements are usually about specific data and specific flows — card handling, KYC data, transaction logs. A monolith makes it hard to draw a clean line around "this is the part that needs to be in PCI scope." Separate services make that boundary explicit and enforceable, not just documented in a wiki nobody reads during an audit.
4. Vendor and rail diversity is a fintech-specific reality. Most consumer apps integrate with a handful of external services. A payments platform integrates with NIBSS, Interswitch, mobile money vendors across multiple countries, bills aggregators, and card processors — each with different reliability, different rate limits, and different failure patterns. Isolating each integration behind its own service means one flaky vendor doesn't become everyone's problem.
None of this is free. You pay for it in operational complexity, in needing real observability, and in engineers who understand distributed systems instead of just CRUD. But in fintech, that cost buys you something monoliths structurally cannot offer at the same level: a guarantee that the blast radius of "something went wrong" stays small.
The sentiment problem
Here's what I think is actually happening in the "microservices are overrated" discourse: people are reacting — correctly — to premature and unnecessary adoption, and generalizing that reaction to every context, including ones where the trade-offs are completely different. The backlash is emotionally satisfying because most of us have seen (or lived through) a microservices horror story caused by a team that didn't need them in the first place.
That's a real problem. It's just not this problem.
Monoliths win the simplicity argument. They win the "you're not Google" argument. They win the argument for teams under ten people building products where a bug means an angry Slack message, not a failed wire transfer. That's a sentimental win — comfort, familiarity, lower cognitive load — and it's a legitimate one.
But in fintech, where the stakes are correctness, containment, and independently scaling systems that move real money through unreliable third-party rails, microservices aren't a trend to grow out of. They're the architecture that matches the actual shape of the problem. The debate isn't "monoliths vs. microservices" in the abstract — it's "what does your system need to contain when it breaks." In fintech, the honest answer is almost always: more than a monolith can promise you.
Top comments (1)
Let me know your thoughts!