—/ Thoughts
The Pragmatic Return of the Modular Monolith
Rethinking SaaS architecture. On why microservices are often premature, how to enforce module boundaries, and when extraction finally makes sense.
An AI-led conversation — a format I chose to keep things honest and to the point.
In recent years, starting a new SaaS project often meant immediately reaching for Kubernetes and a microservices architecture. Yet, we are seeing a strong counter-movement back toward monoliths in early-stage companies. As both an enterprise EM and a startup builder, what is driving this shift?
It's a necessary correction. For too long, our industry has confused "architecture" with "deployment topology." We adopted microservices — a solution designed to solve organizational scaling problems at companies like Netflix or Uber — and applied them to three-person startup teams trying to find product-market fit.
The result was premature complexity. Early-stage teams were spending 40% of their energy building features and 60% managing distributed tracing, service discovery, and complex deployments. The return to the Modular Monolith is a pragmatic realization that network boundaries are expensive. In the early days, velocity is everything. You cannot afford the "distributed system tax" before you have revenue.
40/60 — that ratio alone should make every startup CTO reconsider.
How do you distinguish a "Modular Monolith" from the dreaded "Big Ball of Mud" legacy systems that many engineers fear?
The difference is discipline and structure. A "Big Ball of Mud" has high coupling and low cohesion — everything talks to everything else directly. A Modular Monolith is physically monolithic — it deploys as a single artifact — but logically distributed.
We use Domain-Driven Design (DDD) principles to define strict Bounded Contexts within the same codebase. Module A, say "Billing," should only talk to Module B, say "User Management," through a public, defined interface. It should never reach directly into Module B's database tables. If you enforce these boundaries rigorously in code, you get the organizational simplicity of a monolith with the architectural clarity of microservices.
From your perspective building SaaS startups, what is the primary operational advantage of this approach?
Drastic simplification of the developer experience and operational overhead. When everything runs in one process, debugging is straightforward. Transaction management is ACID by default, not eventually consistent. You don't need a dedicated Platform Engineering team just to deploy "Hello World."
For a startup, this means your limited engineering resources are focused entirely on business logic that differentiates your product, rather than wrestling with infrastructure YAML files.
"Wrestling with YAML files" — every engineer felt that.
Wearing your hat as an Engineering Manager at a large Nasdaq company, what are the risks here? How do you ensure a Modular Monolith doesn't degrade over time?
The risk is high because the path of least resistance in a monolith is always to violate boundaries. It requires strong technical leadership to prevent entropy.
You cannot rely on "gentlemen's agreements" between developers. Modularity must be enforced by tooling. We use tools like ArchUnit in Java, or similar static analysis tools in other languages, to write tests that fail the build if a forbidden dependency is introduced. If the boundary isn't enforced by the CI pipeline, it doesn't exist.
If the boundary isn't enforced by the CI pipeline, it doesn't exist.
When is the right time for a growing SaaS company to move away from the Modular Monolith and finally split into microservices?
You split only when you have a proven compelling reason, never preemptively. There are two main triggers. The first is organizational: when a single team can no longer cognitively own the entire monolith, you split along established module boundaries to align with team structures — Conway's Law.
The second is operational: if the "Video Processing" module has vastly different scaling or resource requirements than the "User Profile" CRUD module, it makes sense to extract it.
The beauty of a well-designed modular monolith is that extracting a service is relatively painless because the boundaries are already defined. You are just swapping an in-process method call for a network call. If you started with a spaghetti monolith, extraction is nearly impossible.
A launchpad, not a destination. That's the right way to frame it.