In the early days of microservices, “small and independent” sounded simple enough. Teams broke apart their monoliths, spun up a dozen new services, and declared victory.
Then came the reality: too many services, endless integration pain, duplicated logic, and distributed complexity that nobody asked for.
Somewhere along the way, the word “micro” became misunderstood. It was never about size - it was about boundaries.
So, what does “micro” really mean?
And how small is too small?
The Size Myth
Let’s start with a misconception: microservices are not defined by lines of code.
A microservice with 500 lines can still be too big - if it mixes domains.
And a microservice with 50,000 lines can still be fine - if it’s cohesive and autonomous.
The essence of a microservice lies in independence:
- It can be developed and deployed independently
- It owns its data
- It exposes clear contracts
- It doesn’t need other services to perform its core function
It’s not about how much code it has, but how much context it owns.
A microservice should be as small as possible, but no smaller than your domain allows.
The Domain Lens: Finding Natural Boundaries
Good service granularity starts with the domain, not the code.
Domain-Driven Design (DDD) teaches us to identify bounded contexts - parts of the business that have their own language, models, and rules. These often map naturally to microservices.
For example, in an e-banking system:
- The Accounts context manages balances and account types
- The Payments context handles transactions and transfers
- The Notifications context deals with messages and alerts
These are clear boundaries. But if you split Payments into Payment Initiation, Payment Validation, Payment Execution, and Payment Logging - you’ve likely gone too far.
You’re no longer modeling the domain. You’re modeling your workflow.
That’s a sign your services are too fine-grained.
The Cost of Small
Granularity comes with a price. Each service adds:
- A new deployment pipeline
- Network overhead and latency
- API versioning and compatibility concerns
- More operational and monitoring complexity
Multiply that by 50 or 100, and “micro” becomes “micromanagement.”
If you find yourself building tools just to manage your services, you may have split too eagerly. The goal of microservices was to enable independence, not to require orchestration frameworks just to keep them talking.
If your architecture diagram looks like a subway map, your services probably aren’t micro - they’re fragmented.
The Signs of Healthy Granularity
So how do you know when you’ve got it right?
A well-sized microservice usually:
- Owns a clear part of the domain (bounded context)
- Has a single, clear reason to change (cohesion)
- Can be deployed independently without coordination
- Contains all the logic it needs to deliver its function
- Has stable external contracts and internal freedom
The Organizational Mirror
Here’s where architecture meets reality:
*The “right” granularity depends on your team structure. *
Conway’s Law tells us that systems mirror the communication structures of their organizations.
If your teams are small, autonomous, and domain-aligned, you can afford more fine-grained services.
If your teams are large, cross-functional, and share ownership, coarser-grained services might work better.
In other words:
The perfect service size is the one your organization can actually operate.
Granularity is not a design decision in isolation - it’s a socio-technical trade-off between independence and coordination.
Evolving Granularity Over Time
Service boundaries aren’t permanent. They evolve as your understanding grows.
Early on, it’s often better to start coarser:
- Combine related functionality into one service
- Avoid over-segmentation until domain boundaries are clear
As your product matures, split where it makes sense:
- When teams struggle to coordinate deployments
- When a service’s model becomes inconsistent
- When scaling or performance needs diverge
This evolutionary approach keeps your architecture aligned with your reality, not with theoretical purity.
Microservices are not designed - they’re discovered, iteratively.
Conclusion - “Micro” Is About Autonomy, Not Size
The word microservice has always been a bit misleading.
The goal was never to make services small - it was to make systems independent.
The right granularity is achieved when:
- Your teams can move fast without tripping over each other
- Your services are cohesive, stable, and aligned with real domains
- Your system’s complexity grows linearly, not exponentially
When you get that balance right, your services stop being “micro” and start being meaningful.
In the end, a microservice isn’t micro because it’s small - it’s micro because it’s focused.
Top comments (0)