Are we microservice yet? More services than people.

The number of services in your system is not the flex you think it is.

A recent Wise post flexing about how they have over 1000 services and 950 engineers triggered a pet peeve about how teams treat service count as some sort of badge of how well they are doing microservices. Like that is the goal in and of itself and not a tool to decompose problems around the people you have.

A service-to-engineer ratio approaching 1:1 means the count has stopped meaning anything.

What a service actually is

A service is a single conceptual unit. One domain, owned end-to-end by one team. The whole thing lives in one repository, so a change to that domain is a single commit. The boundary exists because the business has a real seam there, not because a team wanted independent deployment of a CRUD endpoint.

A deployment unit is something different. The same service might run as an API on Lambda, a queue worker on ECS, and a scheduled batch job at the same time, depending on the isolation and scaling needs. That’s still one service. Counting each deployment unit as a separate service is where the inflation starts.

The other version of inflation is putting each deployable in its own repository. Teams do this thinking it gives them autonomy. What it actually gives them is a coordination nightmare. A change that touches the domain spans three pull requests across three repos that have to land in a specific order, and your CI doesn’t know about any of it. Teams spend real engineering effort to make atomic changes impossible across code that should have been atomic by default. Before claiming a service count, count honestly. How many of those are actual services with their own domain, owned end-to-end by a team, and how many are deployment units of services you already have? A 1000-service org with 100 real services and 900 deployment units is fine. A 1000-service org with 800 actual services that should have been 100 is not. The number itself tells you nothing about which.

How many services should you actually have

The sweet spot is a team of 5 to 10 engineers. That’s enough people to run an on-call rotation that doesn’t burn anyone out, review changes properly, and keep continuity when someone leaves. Below that, ownership starts to fray. Above that, the team is probably big enough to split.

The cleanest case is one service per team. Each team owns its domain and evolves it on its own cadence without coordinating with other teams unless the domain itself requires it. A team can end up with 2 or 3 services as priorities shift and adjacent domains get pulled in. That’s fine. Beyond that, services start to rot — there isn’t enough attention to keep them maintained as people rotate through and the domain shifts. Teams owning many services should be rare.

Apply that to Wise. 950+ engineers in teams of 5 to 10 means 95 to 190 teams. Stretch it to 300 to account for legacy boundaries and organic drift. 1000 is more than three times that.

Why this happens

The original microservices argument was about letting teams ship independently around real domain boundaries. Somewhere along the way that turned into “every new piece of work gets its own service/repo.” It’s easier than negotiating shared ownership, looks good on a tech blog, and signals that you’re keeping up.

The cost shows up later. Lead times look fine on average but cliff hard the moment a change spans four services. There’s a long tail of services nobody has touched in two years, sitting there because the team that built them got reorganised. New engineers take weeks longer to onboard — they have to understand the seams between fifty things to make a change that should have touched one.

Wise aren’t unusual. Most organisations that publicly brag about service count are in the same shape. They just don’t write blog posts about it.

The count itself is the problem. No amount of service mesh, generated clients, or platform tooling makes it cheaper to own a thousand things with a thousand people. The math doesn’t work.

Big organisations are political. Service count moves from metric to goal — we use new services to claim territory and get promoted, even when there’s no good technical reason for the split. That probably explains some of how Wise got here. The other explanation is more charitable: maybe what they call services are really deployment units. For their sake, hope so.