A few years ago, microservices became the default answer to scalability and modernization.
Need to scale? → Microservices.
Need independent deployments? → Microservices.
Need better maintainability? → Microservices.
But there is a question we don't ask often enough:
Did we sometimes introduce microservices where they weren't actually needed?
A simple application that once had:
1 application → 1 database → 1 deployment
can eventually become:
10+ services → multiple databases → API gateways → service discovery → message brokers → distributed tracing → centralized logging → container orchestration → CI/CD pipelines
And suddenly, a simple business transaction becomes a distributed transaction.
The hidden complexity of microservices
Microservices can introduce challenges such as:
🔹 Network latency and failures
🔹 Distributed transactions
🔹 Data consistency issues
🔹 Service-to-service authentication
🔹 Complex debugging
🔹 Deployment and infrastructure overhead
🔹 Version compatibility between services
🔹 Monitoring and distributed tracing
🔹 Increased operational costs
None of these mean microservices are bad.
They simply mean microservices are a trade-off, not a free upgrade.
So when do microservices make sense?
They can be a great choice when you genuinely need:
✅ Independent scaling
✅ Independent deployment
✅ Clear business/domain boundaries
✅ Multiple teams working independently
✅ Different technology or runtime requirements
✅ Strong isolation between capabilities
But if the application is small, the team is small, and the domain boundaries aren't clear, a modular monolith might be a better starting point.
You can still maintain clear modules:
Application
|
+----------------+----------------+
| | |
Orders Payments Users
| | |
+----------------+----------------+
|
Database
And later, when there is a real reason to split a module, it can evolve into a service:
API Gateway
|
+-------------+-------------+
| | |
Orders Payments Users
Service Service Service
| | |
DB DB DB
The real architectural question
Instead of asking:
"Should we use microservices?"
we should ask:
"What problem are we trying to solve, and is microservices the simplest solution to that problem?"
Good architecture isn't about using more technologies.
It's about choosing the right level of complexity for the problem you're solving.
Sometimes that means microservices.
Sometimes it means a modular monolith.
And sometimes, a simple monolith is exactly what you need.
What do you think?
If you were starting a new application today, would you choose:
Monolith 🏠
Modular Monolith 🧩
Microservices 🚀
And most importantly — why?
I'd love to hear what has worked (or failed) in your real-world projects.
