Choosing between a monolith and services

Most teams asking whether to split into services are really asking a different question: why is this codebase slow to change? Sometimes the answer is architectural. More often it is that the domain was never modelled clearly, and distributing an unclear model across a network makes it considerably harder to fix.

What a monolith is actually good at #

A single deployable unit gives you transactions that actually work, refactoring across boundaries with a single commit, and one place to look when something breaks. For most business applications those three properties are worth more than independent scaling.

• Cross-entity operations stay in one database transaction
• A rename can be applied atomically across the whole system
• Local development needs one process, not eight
• Tracing a request does not require distributed tooling

When splitting genuinely helps #

Separation earns its cost when parts of the system have genuinely different operational profiles — a video encoder that needs GPU instances, an ingest pipeline whose load spikes independently, or a component with a different compliance boundary.

The middle ground #

Enforce module boundaries inside the monolith first. If those boundaries hold under pressure for a few months, extracting one becomes mechanical. If they do not hold, you have learned something important for far less than the cost of a distributed system.