Microservices vs Monolith: Why We Still Start With a Monolith

Microservices get associated with "how the big tech companies do it," which makes them an appealing default for a new project that has nowhere near the scale, team size, or operational maturity those companies had when they actually needed to split apart a monolith that had grown too large to manage as one piece.

Why a monolith is usually the right starting point

• A single codebase is dramatically simpler to develop, test, and deploy for a small team, with none of the network overhead and distributed-systems complexity microservices introduce.
• Service boundaries drawn before you actually understand your domain well tend to be wrong, and wrong boundaries in a microservices architecture are expensive to redraw later, unlike a monolith where refactoring internal boundaries is comparatively cheap.
• Debugging a monolith means looking in one place. Debugging a distributed system means tracing a request across multiple services, each with its own logs and potential failure points.

When splitting into services genuinely makes sense

Once a specific part of the system has meaningfully different scaling needs, a different release cadence, or needs to be owned independently by a separate team, extracting it into its own service becomes worth the added operational complexity — the same incremental instinct behind modernizing a legacy system piece by piece rather than all at once.

You can always split a well-organized monolith into services once you understand where the real boundaries are. Un-splitting a premature microservices architecture is a much harder problem to reverse.

This connects to the same principle behind multi-tenant architecture decisions — the right structure follows from real, observed requirements, not from what a much larger company's engineering blog described building for a completely different scale of problem.