"We use a microservices architecture" sounds reassuring in technical interviews. But the teams saying this are often not Netflix, they're a 5-15 person software team.
Remember Conway's Law
Melvin Conway's observation from 1968: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
In practice: if your team is split into 5 parts, your system tends to get split into 5 parts too. When this split is forced, when a microservices architecture is imposed on an organization it doesn't fit, the coordination cost shows up directly in your output.
3 Real Costs
Cost 1: DevOps Overhead
Every microservice means its own CI/CD pipeline, its own monitoring, its own log aggregation. 10 services = 10 deployment units. For small teams, this means spending 30-50% of development time on operations.
Cost 2: Distributed Transactions
If creating an order spans 3 services (Order Service, Inventory Service, Payment Service), what happens when one fails? Saga patterns, compensating transactions, distributed locks... In a monolith, this complexity collapses into a single database transaction.
Cost 3: Debugging Complexity
"Why did I get this error?" is answered with a stack trace in a monolith. In microservices, you may need distributed tracing, log correlation, and an understanding of the service mesh. These are solvable problems, but a serious burden for small teams.
If you frequently hear questions like "there's a communication error between services" or "which service is even calling this?", you may have applied an architecture designed for scale to a team that isn't ready for it.
KELD's Recommendation: Modular Monolith
The modular monolith sits exactly in the middle: a single deployable unit, but with well-defined modules inside it. Each module has its own domain and its own database tables, but everything runs in the same process.
Advantages:
- Single CI/CD pipeline
- Database transactions are available
- Debugging is simple, one stack trace
- Modules can be split into real services later if needed
When Should You Actually Move to Microservices?
3 signals:
- Different services genuinely need to scale independently (a high-traffic feature needs to be isolated from the rest)
- Different teams need different technology stacks
- The organization is already split into domain-based teams, and that split makes sense
If none of these three conditions hold: start with a modular monolith.
Conclusion
Microservices aren't "modern"; they're complex. At the right scale, with the right organization, they're powerful. At the wrong scale, with an unprepared team, they're a disaster. Start from a good monolith, split it when you actually need to.