Microservices Architecture for Fintech: When and How

Every fintech startup eventually faces the monolith vs. microservices question. Myles Ndlovu has built both, and the answer isn’t as straightforward as conference talks make it seem.

Start with a Monolith

This might sound counterintuitive, but almost every fintech should start with a monolith. Here’s why:

You don’t know your domain boundaries yet. Microservices require well-defined boundaries between services. In the early days, you’re still discovering what your product is.
Deployment complexity slows you down. With a monolith, you deploy one thing. With microservices, you deploy ten things that all need to work together.
Debugging is simpler. A stack trace in a monolith shows you exactly what happened. A distributed trace across six services requires specialised tooling.

Start monolithic. Extract services when you have a clear reason.

When to Extract a Service

Extract a microservice when you have at least one of these:

Different scaling requirements: Your payment processing needs to handle 10x the load of your user management. Scaling them independently makes sense.

Different deployment cadences: Your risk engine changes weekly but your KYC service changes monthly. Coupling their deployments creates unnecessary risk.

Team boundaries: Two teams working on the same codebase create merge conflicts and coordination overhead. A service boundary gives each team autonomy.

Fault isolation: If your notification system goes down, it shouldn’t take your payment system with it. Isolating them as separate services provides fault boundaries.

Patterns That Work for Fintech

Event-Driven Architecture

Financial systems are naturally event-driven. A payment is an event. A KYC verification is an event. An account creation is an event.

Payment Received → Event Bus → [Risk Check, Ledger Update, Notification, Analytics]

Each downstream service reacts to events independently. If the notification service is down, the payment still processes. The notification gets sent when the service recovers.

The Saga Pattern

Financial transactions often span multiple services. Debiting one account and crediting another requires coordination. The saga pattern manages this:

Debit Service: Debit sender’s account
Credit Service: Credit receiver’s account
If credit fails: Debit Service reverses the debit (compensating transaction)

Each step has a corresponding rollback action. If any step fails, the saga executes compensating transactions in reverse order.

CQRS (Command Query Responsibility Segregation)

Separate your read and write paths. Writes go through your authoritative service with full validation. Reads come from optimised read models — potentially denormalised views designed for specific query patterns.

This is particularly useful for account balance queries. The authoritative balance lives in the ledger service, but a read-optimised balance cache can serve the vast majority of “what’s my balance?” queries without hitting the ledger.

The Data Problem

The hardest part of microservices in fintech is data consistency. In a monolith, you wrap related operations in a database transaction. In microservices, there’s no distributed transaction that actually works well.

Accept eventual consistency where possible. A user’s transaction list might be a few seconds behind the ledger. That’s usually fine.

Where you need strong consistency (account balances, double-spend prevention), keep those operations within a single service boundary. Don’t split your ledger across multiple services.

Observability Is Non-Negotiable

In a distributed system, you need:

Distributed tracing: Follow a request across service boundaries. Every service adds its span to the trace. When something fails, you can see exactly which service, which call, and which input caused the failure.

Centralised logging: Logs from all services flow to a single searchable platform. Correlate logs using request IDs.

Metrics and dashboards: Latency percentiles, error rates, and throughput for every service. Set alerts on anomalies.

Without these, debugging a production issue in a microservices system is like finding a needle in a haystack blindfolded.

Common Pitfalls

Too many services too early: I’ve seen startups with 3 engineers running 15 microservices. The operational overhead consumed more time than feature development.

Shared databases: If two services share a database, they’re not really separate services. They’re a distributed monolith with network calls instead of function calls.

Synchronous chains: Service A calls Service B, which calls Service C, which calls Service D. Latency compounds. Failure cascades. Use async communication where possible.

No API versioning: Breaking changes in one service’s API shouldn’t break every downstream consumer. Version your APIs and maintain backward compatibility.

The Pragmatic Path

The right architecture is the one that lets your team ship reliable financial software efficiently. For most fintech startups, that’s a well-structured monolith that extracts services as specific needs arise. The goal isn’t architectural purity — it’s serving your customers reliably.