What actually changes with scale
The practices that make five services work do not fail at fifty — they simply stop being sufficient. Nothing on the standard microservices best practices list becomes wrong. What changes is that the cost of every cross-cutting decision gets multiplied by the number of services, and the coordination cost of any change that touches several of them starts to dominate the engineering cost of the change itself.
Concretely: at five services, an engineer can hold the whole system in their head, a shared library upgrade is an afternoon, and "who owns this?" always has an answer. At fifty, none of those hold. Everything below follows from that.
The technical challenges that dominate at scale
Debugging across boundaries
A request that touches twelve services cannot be debugged from logs alone. Distributed tracing stops being a nice-to-have and becomes the primary debugging surface, which means trace context must propagate through every hop including the asynchronous ones — a trace that dies at the message broker is a trace that dies exactly where the hard bugs are. Budget for the retrofit being harder than the original instrumentation: services written before tracing was mandatory will each need touching.
Dependency and version sprawl
Fifty services means fifty upgrade paths for every shared library, base image, and runtime. A security patch that takes an hour per service takes over a week of engineering time across the estate, and that is assuming every service has an owner and a working pipeline. The practices that keep this tractable are unglamorous: a small number of blessed base images, automated dependency-update pull requests, and a published policy on how long a service may lag before it is considered unsupported.
The related problem is inherited dependencies — a service depends on a library that depends on an internal client that depends on a service nobody has thought about in two years. Maintaining an inventory of what depends on what, generated from build metadata rather than a wiki page, is the only version of this that stays accurate.
Data consistency across many owners
With a handful of services, eventual consistency shows up in a few places and each can be reasoned about individually. Across dozens, consistency becomes a systemic property: the same customer record is reflected in eight services, each with its own lag, and reconciliation has to be a scheduled process rather than an incident response. Decide early which service is the source of truth for each core entity and publish that list. Estates without a written answer accumulate two or three competing answers per entity.
The service graph hardening into a coordination graph
The most expensive failure at scale is not technical. It is when the dependency graph becomes so dense that no team can ship without another team's release. This shows up as a rising number of changes that require a coordinated deploy, and it is worth measuring directly — the count of multi-service releases per month is a better health metric for a microservices estate than service count, latency, or deploy frequency.
Platform engineering: the response that works
The consistent answer at enterprise scale is to stop asking every team to solve infrastructure problems and to build a platform that solves them once. What earns its place:
- A golden path. One well-supported way to create a service that arrives with CI, deployment, logging, tracing, metrics, alerting, and an ownership record already wired in. Teams may deviate; the point is that the default is good enough that most will not want to.
- A service catalogue. Every service, its owner, its on-call rotation, its dependencies, its API documentation, and its tier. Without this, incident response starts with a search for the right team.
- Paved-road observability. Tracing, structured logs, and a standard metric set that arrive by default rather than by each team's initiative.
- Self-service environments. If getting a test environment takes a ticket and three days, teams will test in production and you will find out during an incident.
The platform team is a product team whose customers are internal engineers, and it should be measured that way — on adoption of the golden path, not on tickets closed. A platform nobody chooses is a tax.
Governance without a committee
Large estates need consistency in a small number of places and freedom everywhere else. The places consistency genuinely pays:
- API contracts. A shared style guide for naming, pagination, error shapes, and versioning, enforced by a linter in CI rather than by review. See API design best practices and API versioning and schema evolution.
- Authentication and authorisation. One mechanism, one library, one place to fix it. Bespoke auth per service is how estates end up with an unauditable permission model.
- Observability conventions. Consistent metric and span names are what make a cross-service dashboard possible at all.
- Service tiering. Not every service deserves the same SLO or the same on-call burden. Tiering makes the difference explicit instead of implicit.
Everything else — language choice, framework, internal structure, database engine — should be the owning team's decision, with the honest caveat that the platform can only pave so many roads. Two or three supported language stacks is realistic; eight is not.
Record the decisions as architecture decision records held next to the code. The value is not the document, it is that in three years someone can find out why a boundary is where it is instead of assuming it was arbitrary and moving it.
How many services should an enterprise have?
The question is usually asked as a target and is better treated as a consequence. The number that works is the number your teams can own: roughly one to three services per team that the team can operate, be on call for, and keep patched. If services outnumber that, some are unowned in practice regardless of what the catalogue says.
For a fifteen-module application, that maths usually argues against fifteen services. Modules inside a well-structured monolith cost nothing to operate; services cost a pipeline, a dashboard, an on-call rotation, and a place in everyone else's dependency graph. Split when a module has a genuinely different scaling profile, release cadence, compliance boundary, or owning team — and keep the rest as modules.
Migrating a large estate
Enterprise migrations to microservices fail in a recognisable way: a two-year programme, a parallel build, and a cutover that never happens because the old system kept accruing features. The alternative is the strangler pattern applied with discipline — extract the highest-value bounded context first, prove the platform on it, and let each subsequent extraction be independently justified and independently abandonable.
Two things make this survivable. First, the first extraction should be chosen for how much it teaches you, not for how much value it delivers; you are testing the platform, the deployment path, and the organisational model at the same time. Second, every extraction should leave the system shippable, so a change in priorities pauses the programme rather than stranding it.
What to measure
- Multi-service releases per month. Rising means boundaries are wrong.
- Services without a named owner. Should be zero; usually is not.
- Time to create a new service on the golden path. Hours, not weeks.
- Dependency lag. How far behind the oldest service is on the blessed base image.
- Trace completeness. The share of production requests with an unbroken end-to-end trace.
These say more about whether an estate is healthy than uptime does, because uptime stays green right up until the day the coordination cost makes a fix take a week.
Where to go next
For the underlying practices, see Microservices Best Practices. For the named patterns referenced throughout, see Microservices Architecture Patterns. For how large public systems fail and what their operators wrote about it afterwards, see the postmortem readings.