When a monolith is enough, when you split. Conway's Law, team topologies — and why the answer isn't "microservices".
Category · DevOps & Infra
Two architectures, one trade-off.
A monolith keeps the whole application in one codebase and one deployment. Microservices break it into many independent services that are developed, shipped and scaled separately.
Both are legitimate. The split costs complexity — networking, data consistency, operations — and that price has to be justified by a real benefit.
When you split.
Conway's Law says systems mirror the communication structure of their organisation. Microservices make sense when several independent teams have to deliver independently without blocking one another.
Until then we usually build a cleanly structured monolith — faster to develop, simpler to operate, easier to understand. You can split later, deliberately, along the seam that actually hurts.
Why the answer isn't "microservices".
Microservices as a default decision lead to distributed monoliths: all the downsides of distribution, none of its upsides. That's the most common expensive mistake in this field.
The right question isn't "monolith or microservices" but "where does the boundary run at which independent delivery creates real value". Only that boundary justifies the cut.
