Enterprise microservices should scale your organisation, not your API

Microservices were misunderstood from the moment the pattern came to light. It was rarely about the scale of the tech and throughput of services, rather then the scale of the enterprises around the products. It supposed to scale the organization.

Bear with me a little bit, either if you are a microservice-enthusiasts or a hater. Each pattern and tech has its places.

At enterprise scale — multiple tribes, year-long programmes, regulatory constraints, teams across time zones — the bottleneck is never the database query, the API response time or the UX animation length. It's the organisational impulse, the weight of the moving whole. It's the three teams waiting on a single integrator team's API. It's the cross-cutting change that requires a six-week coordination window among 7 squads. (Be real, they are just departments with fancier names at this point.) Or the service that nobody owns fully but everyone depends on, long forgotten who made it, long left the building anyway.

Microservices at this scale work great when they're designed to scale the organisation.

Because it is faster to create small functional things in isolation than use and modify slightly something else that a thousand paying customer relies on daily.

For example, you might have three notification services. One for transactional emails. One for regulatory communications. One for marketing. They overlap. They're not DRY. They might be in three different languages, with different coding standards. And that's fine. Actually even desireable.

Each one is small enough for a single person even to own completely, modify quickly, and ship without coordination. Or anyone to pick up quickly, as to read a couple dozen lines in minutes and you can confidently modify with a good enough test harness around it.

And if you need a fourth — for a new channel, a new regulatory requirement — you write it and deploy it in a sprint. You don't refactor a shared service that three other teams depend on. That a nightly obscure job calls every so often and somehow holds up half the revenue in last quarter. You never mess with something that works.

But you build next to it. This is micro-efficiency over macro-efficiency. Building each service locally, is inefficient. The organisation globally becomes fast just for this reason!

My enterprise-scale Tech North Star package is built around just the right approach for this: choreographed microservices — event stream based, not orchestration — so no single service becomes the bottleneck that the whole programme waits on. No single fault point to bring down the entire revenue stream overnight.

It's not the architecture that looks cleanest in a diagram. It's the one that survives contact with two hundred engineers and a five-year operational horizon.