The microservices architecture is a resume-driven design mistake

6 min read

Let's say it plainly: the microservices architecture is a resume-driven design mistake for the overwhelming majority of UK engineering teams shipping it in 2025. It is a pattern optimised for FASTA-scale org charts, not for the 12-person squad at a Bristol fintech or the platform team inside HMRC. The reason it spreads has almost nothing to do with technical merit and almost everything to do with CVs, conference talks and a generation of staff engineers who learned their trade from Netflix blogs written in 2014. If you are a mid or senior engineer being told to "decompose the monolith" this quarter, push back. Hard.

Why the microservices architecture keeps getting picked

Almost nobody picks microservices because they measured a latency budget, modelled failure domains and ran a cost analysis. They pick it because the staff engineer wants "distributed systems experience" on the next jump, and because the hiring panel at Monzo or Revolut put the word "event-driven" in the job ad six months ago. The decision is made backwards from the offer letter, not forwards from the problem.

You can see it in the job market. Search any UK tech job board and count the listings that demand Kafka, gRPC, service mesh and Istio versus the listings that want someone who can ship a clean Django or FastAPI service on Postgres. The ratio is upside down relative to what most of these companies actually need. We have built a culture where the platform team gets a promotion for cutting a service in half, and nobody gets a promotion for deleting a service that should never have existed. The microservices architecture rewards decomposition as an end in itself.

There is also a subtle social pressure. If your peer at Starling is running 600 microservices on k8s, your 80,000-line Rails app feels embarrassing at the next engineering meet-up. Embarrassment is not an architectural driver. Latency, cost, team cognitive load and deployment risk are. By those measures, a well-structured modular monolith wins for most teams below roughly 50 engineers.

The actual cost of the microservices architecture in GBP

Run the numbers honestly. Each service in a typical UK AWS setup costs somewhere between £80 and £400 a month once you include the cluster overhead, the load balancer, the observability stack, the secrets management, the CI pipeline and the on-call rotation. A modest estate of 80 services is easily £15,000 to £30,000 a month before a single request is served. That is one experienced senior engineer's salary, every month, forever, just to keep the lights on. For a team that could ship the same product as a single deployable, it is pure waste.

The hiring premium you actually pay

The "distributed systems" engineer in London now commands £115k to £150k base, versus £85k to £110k for a strong backend engineer who can design clean module boundaries in a monolith. If your org needs five of them to maintain a maze of 60 services that could have been one codebase, you are spending an extra £300k a year on salaries alone. That is before contractors, before the platform team, before the migration squad. The microservices architecture has a payroll line item, and it is not on the AWS bill.

Where the microservices architecture actually pays off

To be fair, there are real, narrow cases. The defence is not "microservices are always wrong", it is "microservices are almost always wrong for teams that picked them for status". If you are at the BBC and you genuinely need independent deployability for iPlayer, Sounds and News across separate squads with different release cadences, the services are pulling their weight. If you are NHS Digital and you have compliance boundaries that map cleanly to independent data stores, the architecture earns its keep. If you are running a payments system where one service genuinely needs to be in Go for hot-path latency and another is fine in Python for admin tooling, fine. The pattern works when the failure domains, team boundaries and scaling profiles are real and stable.

The signal that you actually need it

The honest test is not "are we big". It is whether your current monolith is genuinely blocking you. Are deploys failing because one team merged a bad migration? Are you hitting a scaling ceiling on a single component that cannot be solved with a bigger box or a read replica? Is a third-party integration in a different language really necessary, or is it just nice? If you cannot point at a concrete, measurable pain that microservices would solve, you do not need microservices. You need better CI, a modular monolith, and a weekend.

What a sensible UK team should do instead

Build a modular monolith with explicit package boundaries, an internal API layer, and disciplined ownership. Stripe famously kept Stripe Payments as a monolith for years for exactly this reason, and it scaled into a multinational giant on a single Ruby codebase. Basecamp and 37signals have written multiple books on this and they are not wrong. Shopify still runs a Rails monolith that handles Black Friday at planetary scale. These are not small shops being precious. These are teams that watched the microservices hype cycle, ran the maths, and chose to spend their complexity budget on product instead of infrastructure.

If you do later outgrow it, the exit ramp is real. Split a service out when you have evidence. Until then, your senior engineers should be paid to keep the monolith boring, not to deploy five new pods a week. The microservices architecture will still be there in five years. It does not need your codebase to justify itself.

Should you apply for that "distributed systems" role anyway?

If the JD leads with Kubernetes, gRPC, Kafka and "event-driven architecture" and the salary is £120k+ London, it is worth a careful look, but not for the reasons the listing thinks. You will learn a lot about failure modes, observability and operational discipline. You will also, statistically, spend half your time shovelling YAML into Argo CD and paging about certificate rotations. In the regions, the same role pays £85k to £105k, which is a 20-30 percent London premium that does not always survive the cost-of-living adjustment. Apply if you actually want to learn the trade. Skip it if you are chasing the title and you would be happier shipping product features from a well-built monolith in Manchester or Leeds. The market is full of companies that picked microservices because their CTO wanted to give a conference talk, and they are quietly hiring senior engineers to clean up the mess. That is a perfectly good job. Just know which one you are walking into.

FAQ: Microservices architecture and your UK tech career

Is microservices architecture experience still worth putting on my CV in 2025?

Yes, but only if you can talk about the trade-offs honestly. Hiring managers at Monzo, Revolut and the big consultancies are tired of candidates who can recite Kafka topology but cannot explain why they chose it. One good paragraph about a service you deleted, or a boundary you refused to split, is worth more than a diagram of 40 services.

What UK salary should I expect for a microservices-heavy senior role?

London senior backend roles with genuine distributed systems ownership sit at £115k to £160k base, often with meaningful equity at fintechs. The same role in Manchester, Bristol or Edinburgh typically pays £85k to £115k. Outside London the gap narrows if the company is remote-first, but the premium for on-call and infra complexity is real.

Should I push back if my team is being told to migrate to microservices?

Yes, with evidence. Ask for the concrete pain being solved, the cost model, and the rollback plan. A migration driven by a director's conference talk is a migration you will be cleaning up in two years. If you cannot get a straight answer, that itself is the answer, and it is worth bringing up before the first service gets cut in half.