Smaller is often better
The default instinct in cloud architecture is to split: more services, more containers, more independent deployments. But splitting has costs that are easy to underestimate and hard to reverse.
A well-structured monolith — or a small set of well-bounded services — is often more reliable, easier to operate, and cheaper to run than a distributed system that was split too early.
When to stay together
- One team owns the code: splitting adds network calls without organizational benefit
- Data is tightly coupled: if two services need a shared transaction, they probably should not be separate services
- The team is small: distributed systems require distributed expertise
The modular monolith
The best of both worlds is often a modular monolith: a single deployable unit with clear internal boundaries. Clean code boundaries without network overhead. Simple deployment without orchestration complexity.
Do not split your architecture because you might need to scale. Split it because you have proven that you need to scale different parts independently.