Microservices are a people problem

Conway's Law states that organizations design systems that mirror their own communication structures. It was proposed in 1967 and it's still true. Your architecture will eventually look like your org chart, whether you intend it to or not.

This means microservices aren't primarily a technical decision. They're an organizational one.

What Conway's Law Actually Means

When two teams own different parts of the system, those parts will evolve independently and eventually diverge. Coupling between them creates coordination overhead—every change that touches both parts requires meetings, alignment, and usually a lot of waiting.

Microservices solve this by making the boundary explicit. Team A owns Service A. Team B owns Service B. They communicate over an API. Neither team needs to know how the other's internals work.

The Problem With Premature Splitting

If you split before you have separate teams with separate ownership, you get the costs of microservices without the organizational benefit. You have:

• Network overhead between services
• Distributed debugging nightmares
• Deploy coordination across multiple services
• One team context-switching across multiple codebases

All the pain, none of the gain.

The Right Trigger

Split a service when:

1. Two teams are stepping on each other's work in the same codebase
2. One part of the system has fundamentally different scaling requirements
3. One part needs to be deployed at a different cadence from the rest

Not because 'microservices are modern architecture.'

The Practical Takeaway

Before you split anything, ask: who owns what after the split? If the answer is 'the same team that owns everything now,' you haven't solved the underlying problem. You've just added network hops.