A team of 10–15 engineers. Series A funded. Processing payments, handling reconciliation, managing compliance. And an architecture that is actively working against them - not because they made careless decisions, but because they made a very common one: they built microservices before they needed them.
The reasoning is understandable. You have read the engineering blogs. You know what happens to monoliths at scale. You have seen the architecture diagrams from companies processing hundreds of millions of transactions. You want to build something that will not collapse when the business grows.
So you architect for the future. Separate services for authentication, payment processing, notifications, reconciliation, reporting - each with its own database and deployment pipeline. It feels responsible. It feels like how mature engineering teams build things.
The problem is that microservices do not solve a technical problem - they solve an organisational problem. Specifically, the problem of multiple large teams needing to deploy independently without stepping on each other. If you do not yet have that problem, you have added enormous operational complexity for a benefit you will not see for years. And you pay the cost every single sprint.
The symptoms are consistent across every early-stage fintech company that makes this architectural choice:
A change touching business logic requires coordinated updates across multiple services, multiple repositories, multiple deployments. What should be one pull request becomes a cross-service project.
A payment failure originating in one service propagates through three others before surfacing as an error. Without mature distributed tracing in place, finding the root cause means correlating logs across systems manually.
Understanding how twelve services interact, what each owns, and how data flows between them takes weeks. In a well-structured single deployment, a new engineer can be productive in days.
Payments require strong consistency. When logic for a single payment operation is spread across multiple services, managing transactional integrity without a shared database is genuinely hard - and the edge cases compound over time.
Architectural decisions rarely come with a financial model attached. For payment companies, they should.
| Cost Category | How It Compounds | Annual Impact (12-person team) |
|---|---|---|
| Operational overhead (20% of engineering capacity) | Managing service dependencies, deployment pipelines, inter-service failures | Material engineering time; quantify from team size, loaded cost and time spent on platform overhead |
| Debugging overhead on payment failures | Incidents affecting revenue take 3–5× longer to diagnose | Incident cost varies by duration, transaction volume, customer impact and recovery work |
| Delayed features in a competitive market | Every sprint delivers 3–4× fewer features than architecturally possible | Compound competitive disadvantage |
| Compliance debt | PCI DSS audit surface expands with every additional service | Assessment and remediation effort depends on scope, evidence quality and the validating organisation |
The architecture decision made in week two of the company is still being paid for three years later. The debt is not technical - it is financial, operational, and competitive.
The answer is not always a monolith. But it is almost never twelve services either. For most fintech companies at the seed-to-Series B stage, the architecture that serves them best looks like this:
Handles primary payment and business logic - authorisation, capture, settlement, reconciliation - structured well internally with clear module boundaries, but deployed as a single unit. Idempotency, state orchestration, and async processing are built in from day one. The Sync Your Cloud Infrastructure Readiness tool scores this layer directly.
A separate service only when complex analytical queries would compete with transactional workloads. Typically an RDS read replica or a separate Redshift pipeline fed by DynamoDB Streams. Not a microservice - a deliberate scaling boundary with a clear reason to exist.
SNS + SES for email/SMS notifications. Separated from the core payment service only when notification volume genuinely justifies independent scaling - typically above 100k notifications per day.
This is not a compromise or a stepping stone. It is the correct architecture for the context. It keeps your team focused on building the product, not operating infrastructure. And when you genuinely need to extract a service because a specific component is under real scaling pressure, or because a new team owns it, you have a clean, well-understood codebase to extract from.
The most acute technical cost of premature microservices in a payments context is distributed transactions. Payments, by nature, require strong consistency. A payment must either complete or not - partial completion means financial loss, reconciliation failures, or compliance violations.
When payment logic is spread across multiple services - fraud check in one, authorisation in another, settlement in a third - every operation that crosses a service boundary is a potential consistency failure. You need the saga pattern via Step Functions, which means compensating transactions for rollback, idempotency at every boundary, and DLQs for every event that can fail. This is solvable - but it requires the same engineering sophistication that your microservices architecture was supposedly providing room for.
PCI DSS scope is determined by the flow of cardholder data. In a payment microservices architecture, cardholder data often flows through more service boundaries than it needs to, expanding your CDE scope and multiplying your audit surface. A QSA reviewing a 12-service architecture at a 15-person company will ask why every one of those services is in scope - and the honest answer is usually that they do not need to be.
The decision nobody is asking: Before choosing microservices for your payment platform, ask whether the operational overhead is being paid today - in sprint velocity, debugging time, and compliance cost - to solve a scaling problem that does not yet exist. For most fintech companies under £5M ARR, the answer is yes.
A Sync Your Cloud membership gives your team on-demand payment infrastructure expertise - covering service design, idempotency, compliance scope, and cost - with written recommendations your engineers can act on immediately.