Five years ago, “microservices” was the automatic answer to “how should we structure this system?” for anyone who wanted to be taken seriously. Three years ago, the pendulum started swinging back — modular monoliths, “majestic monoliths,” DHH’s “we-re-monolithed-Basecamp” essays. Today, the reflex has flipped again in some circles — anyone who says “microservices” gets an eye-roll.
Both reflexes are wrong. The choice is a genuine trade-off, and picking well requires looking at the specific project rather than the current fashion.
Here’s the framework we actually use.
The three canonical shapes
Monolith
One codebase, one deployable artefact, one database (usually). Grows organically, refactors difficultly.
- Cheapest to build and deploy in year one.
- Fastest end-to-end feedback loop for a small team.
- Hardest to scale beyond ~15 developers without discipline.
- Weakest at isolating failure domains.
Modular Monolith
One deployable artefact — but internally structured as a set of modules with strict boundaries. Modules communicate through explicit APIs (in-process, but explicit). Sometimes each module owns its own schema within the shared database.
- Almost as cheap as a plain monolith in year one.
- Almost as scalable as microservices with the right module discipline.
- Requires actual architectural discipline — without it, degenerates into a monolith with worse ergonomics.
- Standard target for most enterprise apps built today.
Microservices
Many deployable artefacts. Each owns its data. They communicate over the network (HTTP, gRPC, events).
- Highest operational cost — you’re running a distributed system now, whether you wanted to or not.
- Best fit for organisations with multiple teams that need to move independently.
- Highest resilience ceiling — if designed well.
- Highest total complexity ceiling — will you actually need it?
The three-question filter
Before any architecture discussion, run these three questions.
1. How many independently-deploying teams will this system have?
- 1 team → monolith, or modular monolith if the domain is complex. Microservices are almost never justified.
- 2–4 teams → modular monolith with strict module boundaries, maybe transitioning to a small set of services at the seams.
- 5+ teams → microservices become genuinely useful. Team autonomy overtakes deployment simplicity as the top concern.
The Conway’s Law version of this: architecture will mirror communication structure. If you have one team, a microservices architecture will still communicate like a monolith and you’ll pay the cost of both. If you have five teams, a monolith will develop internal service-like boundaries anyway and you’ll pay the cost of neither.
2. What’s the actual scale ceiling — and how far are you from it?
- If year-3 projected load is comfortably served by one instance of a well-written monolith → the scale case for microservices is weak. Vertical scale and read replicas cover a lot of ground in 2026.
- If year-3 load requires horizontal scale of specific subsystems (heavy computation, real-time streaming, high-volume writes) → extract those subsystems into services. Don’t microservice-ify the whole thing.
- If the system already has cleanly separated hot subsystems on different scaling curves (batch analytics, real-time serving, admin console) → this is the actual case for microservices.
3. How different are the failure and consistency requirements across parts of the system?
- All-or-nothing consistency, low tolerance for eventual consistency? → monolith or modular monolith. Distributed transactions are miserable to build and worse to debug.
- Different subsystems can tolerate very different consistency and availability guarantees? → services boundaries can be drawn at those seams. E.g., billing (strongly consistent) vs. product recommendations (eventually consistent, high availability) is a natural service split.
What “modular monolith” actually looks like
The most misused term in this conversation. A modular monolith is not “a monolith with a folders/features directory.” It’s a monolith with genuine module boundaries. Practically:
- Each module has a public API other modules must go through. No cross-module deep imports.
- Each module owns its data. Same database, but strict per-module schema ownership. Cross-module reads go through the module’s API, not through a JOIN in another module’s code.
- Compile-time boundary enforcement (module systems, Rust crates, TypeScript project references, Java Modules, C# csproj boundaries, Rails engines, Django apps with explicit interfaces).
- Independent testability per module. If Module A can only be tested with Module B running, they’re not modules — they’re a monolith wearing a costume.
Done right, a modular monolith can serve 30–50 developers without collapsing. Done poorly, it’s worse than a plain monolith because it adds ceremony without giving you the benefit.
When to extract a service from a modular monolith
Not “when the module gets big.” That’s a monolith with big folders.
Extract a service when at least one of these becomes true:
- Independent scale profile. The module has a fundamentally different load pattern (spiky vs. steady, compute-heavy vs. IO-heavy).
- Independent deployment cadence. The module needs to ship on a different rhythm from everything else (e.g., a payments module that batches releases quarterly, vs. product features that ship weekly).
- Team boundary. A new team owns the module and needs to deploy independently.
- Language / runtime fit. The module genuinely benefits from a different language (heavy ML → Python; real-time streaming → Go or Rust).
If none of these are true, extracting a service costs more than it saves. Keep the module in the monolith.
What we default to per project shape
- Solo founder to 5 engineers, product still finding shape → monolith. Every hour spent on architecture is an hour not spent finding product-market fit.
- 5–15 engineers, product model stable, complex domain → modular monolith. This is the correct answer more often than anyone admits.
- 15+ engineers, multiple product areas, real scale → modular monolith + a small number of extracted services at natural seams (auth, billing, search, heavy async workers). Rarely a full microservices architecture.
- Multiple teams, multiple products, independent release trains, real scale, real ops capacity → services architecture. Yes, plural teams matter. If you have one team calling itself “the platform team” and one team calling itself “product,” you have two teams — not enough for a full microservices bet.
The costs nobody puts in the microservices business case
If you’re considering microservices, add these to the estimate honestly:
- Distributed tracing infrastructure. You will not survive without it.
- Service mesh or equivalent. Sidecars, TLS, retries, circuit-breakers, service discovery.
- Contract testing across service boundaries. Consumer-driven contracts, Pact-style setups.
- Idempotency and retry semantics on every write path that crosses a service boundary.
- Local development environment complexity. Running 15 services on a laptop is a real problem. Devcontainers and Docker Compose help. They don’t make it invisible.
- Deployment coordination. Backward-compatible API evolution as a first-class concern.
- Data consistency compensation. No more transactions across services. Sagas, outbox pattern, event sourcing where appropriate.
- On-call complexity. More surface area, more paging, more runbooks.
None of these are un-solvable. All of them cost real time, real money, and real team attention. Add them to the year-one budget honestly.
Two things worth stating out loud
One: the correct architecture for most enterprise systems built today is a modular monolith. Not because microservices are bad, but because most systems don’t need what microservices offer and can’t afford what they cost. If your architecture answer feels contrarian, check whether it is — or whether you’ve just internalised the fashion.
Two: you can absolutely start as a modular monolith and evolve to services later. The reverse — starting as microservices and consolidating into a monolith — is more common in confessional blog posts than most teams admit. Every migration from microservices back to a monolith we’ve seen was a painful project driven by ops cost overruns. Don’t pay that price optionally.
The Uber question
Somebody will bring up Uber. Or Netflix. Or Amazon. All three of them ended up on microservices architectures. Doesn’t that prove microservices?
It proves that at Uber / Netflix / Amazon scale, with Uber / Netflix / Amazon organisational shape, microservices are the right answer.
You’re not at that scale. You don’t have that organisational shape. The right architecture for your project is the one that matches your project — not the one that matches Uber’s.
Where Parth Infotech sits
Our default for enterprise engagements under 15 engineers is modular monolith — usually Rails, Django, ASP.NET or Spring, structured with strict module boundaries. Around 20% of engagements have justifiable extraction of specific subsystems into services (usually async workers, sometimes an auth service, occasionally a high-scale read path). Fewer than 5% are architected as full microservices from day one, and every one of those had specific organisational and scale reasons that were true from the outset.
If your project is heading towards a microservices answer by default, we’re happy to sit in a scoping call and pressure-test it.
Related: The solution architect’s checklist for enterprise projects covers the broader architecture-decision framework this question sits inside.
