Monzo's Microservice Estate
Monzo runs a bank on well over a thousand microservices, and the interesting engineering is in the platform and network isolation that makes that number survivable.
The situation
Monzo has published openly about operating a licensed UK bank on an estate that passed 1,500 microservices — an extreme position, and one they defend on the grounds of team autonomy and independent deployability rather than performance.
What makes it work
A very strong platform. Services are generated from a template that supplies networking, deployment, observability, tracing and libraries. Creating a service is a routine action taking minutes, and every service is consistent by construction. This is the paved road, and at that count it is not optional — inconsistency across 1,500 services would be unmanageable.
Uniform observability. Consistent structured logging, metrics and distributed tracing across everything, because no human can hold the call graph in mind.
Network-level isolation. Their published work on Calico network policy is the piece most relevant to regulated environments: by default any service could reach any other, which for a bank is an unacceptable lateral-movement surface. They generated per-service network policies from actual observed traffic, moving from a flat network to explicit, enforced service-to-service rules.
Asynchronous, event-driven integration for much of the flow, so services are not chained synchronously into fragile call stacks.
The honest reading
Monzo is evidence that a very large service count can be operated safely, and equally evidence of what it costs: a substantial platform team, uniform tooling, and engineering effort that a smaller organisation would spend on product.
The transferable lesson is not the number. It is that service count is bounded by platform maturity. An organisation with 1,500 services and no platform has 1,500 snowflakes; one with a strong platform has 1,500 instances of one well-understood thing. Before adding services, ask which of those you are building.
The network-policy work is worth copying regardless of scale: a flat internal network is a compromise waiting to be amplified, and generating policy from observed traffic is a practical way to reach least privilege without guessing.