Microservices are often presented as a way to set teams free. Each team owns a part of the product and releases it without waiting for the others. It sounds attractive. But if every meaningful change still needs five approvals, splitting the software has not created independence. It has merely introduced more things to run.
So I would not start by asking how many services the company needs. I would ask which dependency is slowing the business down, and whether a service boundary will actually remove it.
Independence is not a service count
Think of an online store. Catalog changes frequently, payments need cautious releases, and notifications move at another pace. When they all share a deployment, one team may end up waiting for another.
Separate services can give teams independent releases, infrastructure suited to their workload and the ability to scale one busy capability without scaling the whole product.
But this works only with clear ownership and reasonably stable contracts. If the catalog service reads payment tables directly, the teams remain coupled. Putting their databases on separate servers would not fix the organisational dependency.
One customer action, several systems
A shopper clicks “Place order.” In a monolith, parts of that operation may fit into one database transaction: either the changes commit together or they do not. In a service architecture, orders, inventory and payments may belong to different systems.
Now imagine the order was created but the payment service did not respond. What does the customer see? Can the payment call be retried without charging twice? When should reserved stock be released?
These questions require explicit states, safe retries, duplicate handling and perhaps compensating operations. None of that makes microservices inherently wrong. It is simply part of their price — one that rarely appears in the first architecture diagram. Customers experience one product and should not have to understand its internal service boundaries.
Failures become harder to explain
When a request crosses several services, it can fail at a network hop, through a timeout, an incompatible contract, a backed-up queue or an unavailable dependency. Every service may look healthy in isolation while checkout still fails.
You need end-to-end tracing, sensible timeouts, backpressure, safe retries and clear failure behaviour. Separate deployment does not guarantee fault isolation either. If services synchronously depend on one another, an overloaded component can slow the entire chain.
There is also a permanent organisational bill: who owns shared contracts, who gets paged at night, how are changes coordinated, and where does one team's responsibility end? Splitting capabilities arbitrarily creates more of these boundaries, not fewer.
When the business actually benefits
Microservices have a stronger case when several teams own distinct product capabilities with different scaling and release needs, and a shared application is already slowing them down. Then separate services may reduce delivery dependencies and let each area evolve on its own.
I would measure outcomes: are changes moving through delivery faster? Are teams spending less time waiting? Is the blast radius of failures smaller? Or has incident investigation become so much slower that independent releases no longer look like a bargain?
If the team is small, responsibilities still change frequently and the delivery pipeline is already fast, distributed boundaries may be an expensive answer to a question nobody asked.
Find the boundary before extracting the service
I would resist splitting a tightly coupled application into dozens of services at once. First, establish ownership of data and business operations, reduce accidental dependencies and see how far a modular monolith can take the organisation.
If one capability truly needs a different operating model, extract it incrementally. Real requirements for remote APIs, failure handling and diagnostics will become visible. That is a better foundation for the next decision than an architecture diagram designed for a hypothetical future.
Microservices earn their place when an organisation can use the independence they offer — and can afford the complexity required to keep it.