Monolith vs Microservices vs Modular Monolith

You've learned about monoliths, microservices, and modular monoliths. You understand their characteristics, benefits, challenges, and evolution paths. Now comes the critical question: Which architecture is right for your situation?

This isn't a question with a universal answer. The right architecture depends on your organization, your product, your team, your scale, and your constraints. What works for Netflix doesn't work for a 10-person startup. What works for a startup finding product-market fit doesn't work for an enterprise with 500 developers.

This page provides a decision framework—a structured approach to evaluating your context and making an informed architectural choice. This isn't a flowchart that produces 'the answer'; it's a thinking tool that helps you weigh factors and make defensible decisions.

Architectural decisions should be made systematically, considering multiple factors. Here's a framework that organizes the key dimensions:

The Core Principle:

Choose the simplest architecture that solves your current problems while remaining evolvable.

This principle has two implications:

1. Don't solve imaginary problems — If you don't have scaling problems, don't architect for scale you might never reach. If teams aren't blocked, don't add independence overhead.

2. Don't paint yourself into a corner — Build in a way that evolution is possible. A well-structured monolith can evolve; a poorly structured one traps you.

Team size is one of the strongest predictors of appropriate architecture. Microservices require enough people to staff autonomous teams. Without this, you're adding complexity without gaining independence.

Team Structure Matters:

Beyond size, how teams are organized affects architectural fit:

Functional Teams (frontend, backend, DBA, QA) — Favor monoliths. Cross-functional services require cross-team coordination for every change.

Feature Teams (team owns a feature end-to-end) — Can work with modular monoliths. Each team owns modules; coordination happens through APIs.

Product Teams (team owns a product area completely) — Fit for microservices. Teams can own services, make technology choices, and deploy independently.

Conway's Law Applies:

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

If your teams communicate constantly, your services will be tightly coupled. If you want loosely coupled services, you need loosely coupled teams. Architecture follows organization.

Wrong service boundaries are extremely expensive to fix. In a monolith, refactoring boundaries is a code change. In microservices, wrong boundaries require re-architecting infrastructure, migrating data, and renegotiating team responsibilities.

Your understanding of the domain directly impacts your ability to draw correct boundaries.

Signs of Low Domain Understanding:

• Requirements change significantly week-to-week
• Stakeholders disagree on core concepts
• Similar functionality is being built in multiple places
• 'Product' means different things to different teams
• You're still learning what customers actually need

Signs of High Domain Understanding:

• Requirements are stable and well-documented
• Ubiquitous language is shared across the organization
• Bounded contexts are clear and agreed upon
• Changes are extensions, not fundamental shifts
• The product has been running in production for years

Scale requirements affect architecture choice, but not as simply as 'big = microservices.' What matters is differential scaling needs—whether different parts of your system have vastly different capacity requirements.

When Scale Justifies Extraction:

1. Extreme Differential — If one component genuinely needs 10-100x the capacity of others—not a hypothetical, but an actual measured need—extraction saves significant infrastructure cost.

2. Different Resource Profiles — One component is CPU-bound, another is memory-bound, another is I/O-bound. Optimal hardware differs.

3. Database Bottleneck — A single database can't handle the load. You need to partition, and the partition aligns with a service boundary.

4. Different Availability Requirements — Some features can tolerate occasional downtime; others are revenue-critical and need maximum availability.

When Scale Doesn't Justify Extraction:

• Scaling hypothetically ('what if we go viral?')
• All features scale proportionally
• Scale is 2-3x different, not 10-100x
• Caching or optimization would solve the problem
• Vertical scaling is still an option

Microservices require operational sophistication that many organizations lack. Without it, microservices become operational chaos. This factor is often underweighted in architecture decisions.

The Operational Cost Reality:

Microservices create operational load that compounds:

• N services = N deployments to monitor — Each service can fail independently. Alerting noise increases.
• N services = N log streams — Finding the relevant log requires correlation across streams.
• N services = N potential failure points — Debugging requires understanding all possible failure modes.
• N² potential service interactions — Each service can call each other. Failure modes multiply.
• N database connections — Connection pooling becomes complex.

Without sophisticated tooling and processes, this operational load overwhelms teams.

Combining all factors, here's a comprehensive decision matrix. For each factor, assess your situation and see which architecture pattern fits best.

How to Use This Matrix:

1. Assess Each Factor — For each row, determine which column best describes your situation.

2. Count the Columns — Which architecture gets the most tallies?

3. Weight Critical Factors — Some factors may be decisive in your context. Operational maturity, for example, is often a hard constraint.

4. Consider Trajectory — Where will you be in 18 months? If you're 10 developers growing to 50, plan for future state.

5. Beware Single-Factor Decisions — If only one factor points to microservices (e.g., 'we need polyglot'), question whether that's enough to justify the overhead.

Architecture decisions must be communicated and defended to stakeholders—leadership, peers, and future team members. Here's how to structure that communication.

Handling Pushback:

You will face pushback. Here are common objections and responses:

"Netflix/Uber/Google uses microservices"

They have thousands of engineers and dedicated platform teams. We have 20 people. Their solution doesn't fit our context.

"Monoliths don't scale"

Stack Overflow serves 1.3B monthly views on a monolith. Shopify processes billions in transactions. Scale is about optimization, not architecture.

"We'll be stuck with old technology"

A modular monolith can evolve. When we need extraction, boundaries are already defined. We're not preventing future evolution.

"Microservices are the modern approach"

Architecture should solve problems, not follow trends. What specific problem would microservices solve that we can't address with our chosen approach?

Architecture decisions aren't permanent. Conditions change, and decisions should be revisited when the context that informed them shifts.

Building in Review Cadence:

Don't wait for crisis. Schedule periodic architecture reviews:

1. Quarterly Architecture Check-In — Is the current architecture serving us? Any emerging pain points?

2. Annual Architecture Review — Deep dive. Revisit the original decision. Has context changed?

3. Trigger-Based Reviews — When specific thresholds are crossed (team size, traffic, deployment frequency), automatically review.

The Reversibility Principle:

Remember that moving toward complexity is hard to reverse. Extracting services is straightforward (if boundaries are defined). Re-consolidating services into a monolith is very difficult. This asymmetry should bias you toward waiting until evolution is clearly needed.

We've established a comprehensive framework for making architectural decisions—not based on trends or idealism, but on the specifics of your situation.

The Final Word:

There is no universally 'best' architecture. There is only the architecture that best fits your context—your team, your product, your constraints, your goals. The framework and principles in this module enable you to make that choice deliberately, defend it rationally, and evolve it as conditions change.

The best architects aren't those who know the most patterns or follow the latest trends. They're those who understand context deeply, make informed trade-offs, and adapt as they learn. With the knowledge from this module, you're equipped to do exactly that.