Architecture Patterns Explained: Monolith, Modular Monolith, Microservices, and Serverless as Decision Frameworks
“We use microservices” can signal technical maturity — or it can signal over-engineering that exceeds the team’s actual capability. Architecture is not a question of which pattern is technically superior. It is a business decision that simultaneously determines four variables: team size constraints, development velocity, operational cost tolerance, and future organizational design.
For M&A professionals and VC investors, evaluating architecture is not about judging technical quality. It is about asking whether the architectural choice fits the current phase — and whether the complexity of the design is proportionate to the organization’s actual capability.
The Essence of Architecture: A Mirror of the Organization
Software architecture researcher Melvin Conway proposed the following in 1967:
Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
This is known as Conway’s Law. Though observed over 50 years ago, it is regularly confirmed in practice today. Software built by a 10-person company and software built by a 1,000-person company should look structurally different — and rightly so.
The practical implications are twofold. First, changing the architecture requires changing the organization. A decision to “migrate to microservices” is an organizational transformation involving team splits, communication redesign, and CI/CD buildout — not a technical problem. Second, adopting an architecture more complex than the organization’s maturity guarantees failure. When a 3-engineer team tries to operate microservices, one person ends up owning multiple services, eliminating the purpose of the split.
When evaluating architecture at an investment target, asking “what did they choose” is only half the question. The other half is “do they have the organization to support that choice?”
Monolith: The Misunderstood Strengths
“Monolith” is often framed as an outdated design choice — but this is a misconception. Precisely defined, a monolith is a system that runs as a single process: all functionality lives in one codebase and is deployed together.
The monolith’s strength comes from the simplicity that drives development velocity.
The most important characteristic of a monolith is function-call-level communication cost. When Feature A needs Feature B’s logic, it calls it directly within the same process. In microservices, that call becomes a network-based API request. This isn’t just a speed difference — it’s a difference in failure complexity. “How do we design retries when the A→B network call fails?” is a problem that simply does not exist in a monolith.
The case for starting with a monolith at the early startup stage is clear: when the development team is small enough for everyone to understand the entire codebase, keeping the code in one place produces higher velocity. At a scale where one person can verify end-to-end consistency, the cost of building the machinery to maintain cross-service consistency — API versioning, schema definitions, contract testing — exceeds the benefit.
The persistent misconception that “monolith equals technical debt” conflates two separate concepts. Technical debt is the accumulation of unacknowledged design compromises. A well-organized monolith is far healthier than a spaghetti microservices deployment.
Modular Monolith: The Middle Ground Between Monolith and Microservices
A modular monolith still runs as a single process — like a traditional monolith — but introduces explicit, enforced module boundaries (domain boundaries) internally. Each module owns its internal data, logic, and interface, and communicates with other modules only through its published API.
Many of the problems with traditional monoliths stem from their “anything can access anything” nature. A modular monolith prevents this structurally. Because modules still communicate via function calls within the same process, there is no network communication cost.
When a modular monolith delivers value
A modular monolith is particularly effective in these situations:
- The team has grown to 10–50 people and the codebase needs structure — When the team has exceeded the scale where everyone can hold the whole system in their head, domain boundaries reduce cognitive load
- A future microservices migration is on the roadmap — A modular monolith with clear boundaries makes it straightforward to later extract individual modules as services
- The team isn’t yet ready for microservices operational complexity — DevOps, distributed tracing, and service mesh investment haven’t caught up yet; a modular monolith allows boundary-design practice without that overhead
Comparison: monolith vs. modular monolith vs. microservices
| Monolith | Modular Monolith | Microservices | |
|---|---|---|---|
| Deployment unit | Single release | Single release | Per-service independent |
| Inter-module communication | Function call (unrestricted) | Function call (public IF only) | Network (HTTP / message) |
| Data ownership | Shared DB | Each module owns its data | Each service owns its DB |
| Development velocity | ◎ High | ○ High | △ Improves after team split |
| Boundary enforcement | ✗ None | ○ Enforced in code | ◎ Enforced by process boundary |
| Operational complexity | ○ Low | ○ Low | △–× High |
| Recommended phase | ≤10 people | 10–50 people | 50+ people |
Shopify has long operated on a modular monolith, organizing its Rails application into units called Components and extracting only specific functions as services when needed. In public engineering blog posts, the team has described the modular monolith as the foundation that enabled fast early development — a real-world example of phase-appropriate architecture choice.
Migrating to a modular monolith
Transitioning an existing traditional monolith to a modular monolith is relatively straightforward. First, identify domains (users, orders, payments, etc.), then reorganize the corresponding code into dedicated directories (/modules/user/, etc.). Next, identify any code that directly accesses database tables across domain boundaries and refactor it to go through published interfaces.
This migration can be done incrementally alongside ongoing feature development — no feature freeze required. The absence of a complete rewrite is the key practical difference from microservices migration.
Microservices: Conditions for Success and the Pitfalls
Microservices decompose a system into independently deployable services, each owning its own process, database, and deployment lifecycle. Amazon’s adoption in the mid-2000s to handle explosive growth established microservices as “the correct architecture for scalable large-scale systems.”
However, Amazon’s team at the time of adoption numbered in the thousands of engineers. Ignoring this scale context is the most common source of premature microservices adoption among startups.
When Microservices Actually Work
Microservices deliver their intended value only when these conditions are met:
- Multiple teams need to develop and deploy independently — For teams under 10 people, the cost of maintaining cross-service consistency exceeds the benefit of independent deployment
- Different features have significantly different scaling requirements — “Payments spike at month-end, authentication is uniform” is a legitimate reason to scale them separately
- DevOps capability exists to maintain CI/CD, monitoring, and a service mesh — Microservices transfer infrastructure management complexity into the application layer; this requires dedicated DevOps investment
The Distributed Systems Complexity That Gets Overlooked
Adopting microservices introduces an entire class of problems that don’t exist in a monolith.
Distributed transaction problem: If “create order” and “decrement inventory” live in separate services, what happens when the order is created but the inventory decrement fails due to a network error? In a monolith, a database transaction solves this cleanly. In microservices, it becomes an eventual consistency problem requiring careful design.
Observability complexity: When a single API request traverses five services to complete, identifying where latency occurs requires distributed tracing infrastructure. This is an additional operational cost that doesn’t exist in a monolith.
When evaluating an investment target that uses microservices, the key question is “why did they decompose it?” If the answer is “microservices are modern” or “the CTO used it at their last company,” the company is likely carrying design complexity costs that don’t match the phase.
Serverless: Cost Model and Constraints
Serverless is an execution model where code runs as discrete functions (Functions) without developers managing any server infrastructure. AWS Lambda, Google Cloud Functions, and Cloudflare Workers are the primary examples.
The name “serverless” is misleading — servers exist, but the cloud provider manages them and developers don’t need to think about them.
The Economics of Serverless
Serverless billing is purely consumption-based: execution duration × memory allocation × invocation count. With no always-on servers, cost is zero during zero-traffic periods.
This creates strong economics for specific use cases:
| Use case | Serverless fit | Reason |
|---|---|---|
| Batch processing / overnight jobs | ◎ Excellent | Billed only for execution time; no idle cost |
| Webhook handlers / event processing | ◎ Strong | Ideal for infrequent, unpredictable events |
| Always-on API servers | △ Conditional | Cold start latency; execution time limits apply |
| Long-running batch processing | × Poor | Execution time caps (typically 15 min–1 hour) |
| WebSockets / real-time communication | × Poor | Stateless design makes persistent state difficult |
Cold Start and Execution Time Limits
Two constraints deserve attention in investment and technical evaluation:
Cold start problem: After a period of no requests, the first invocation incurs a cold start — the function container is initialized — which can add tens of milliseconds to several seconds of latency. For APIs requiring sub-100ms response times, this is material. Provisioned concurrency (keeping containers warm) mitigates this but increases cost.
Stateless-first design: Serverless functions cannot retain state across requests. Sessions, connection state, and in-flight data must live in external storage (databases, caches). This constrains design choices but is the same property that makes horizontal scaling trivial.
Phase-Based Architecture Recommendations for Startups
The rational architecture choice changes by business phase.
The key principle: adopting an architecture that is ahead of the current phase creates technical debt, not prevents it. A 10-person team on microservices will spend more time maintaining cross-service consistency, deployment pipelines, and complex local development environments than writing product features. This is the canonical instance of the “over-engineering steals velocity” pattern described in our analysis of AI-driven development and technical debt risk.
Architecture Evaluation for Investment and M&A
With this framework in place, here are the specific evaluation angles relevant to investment and acquisition decisions.
Accountability for “Why This Architecture”
Whether the team can explain their choice is itself a maturity indicator. In response to “we use microservices,” ask: “When and why did you decompose it, and what trade-offs did you make?”
A well-reasoned choice produces a clear answer. “We started with microservices because it’s the modern approach” or “that’s what we used at our last company” signals that technical decision-making culture has not matured.
Alignment With Scaling Strategy
Ask: “If traffic grows 100x over three years, how does the current architecture scale?”
For a monolith, the follow-up questions are about horizontal scaling and database bottlenecks. For microservices, the expected answer is “we can identify the bottleneck service and scale only that.” The quality of the response tells you whether the engineering team has an accurate model of their own system’s bottlenecks.
Migration Cost Recognition
In M&A technical due diligence, assessing whether architectural migration is necessary — and what it would cost — is often part of the scope.
Monolith-to-microservices migration can be done incrementally. The standard approach is to first extract high-independence features (notifications, batch jobs, image processing) while leaving core business logic intact until last. Full rewrites carry the highest risk; the “strangler fig pattern” — gradually replacing the existing system with new services that take over its routes — is the recommended approach.
If migration cost estimates are vague — if the answer is “that part is tangled and hard to touch” — this signals that technical debt has not been made visible, which is itself an organizational risk.
Five Questions to Ask in Any Architecture Evaluation
- “What was the reasoning for your current architecture, and what trade-offs did you knowingly make?” — Assesses the quality of technical decision-making
- “What is your deployment frequency and lead time per release?” — Quantifies operational health (healthy monolith: weekly to daily; microservices expectation: each team deploys independently, multiple times per day)
- “When a production incident occurs, how long does root cause identification typically take?” — Reveals monitoring maturity relative to architectural complexity
- “If you doubled the team, would development velocity also double with the current architecture?” — Tests alignment between scaling strategy and architectural design
- “Which part of the system would you most want to refactor, and why?” — Surfaces technical risk through the engineers’ own lens
Summary: Architecture as a Readout of Decision Quality
The four patterns have no inherent ranking. What matters is fitness for phase, organization, and business objectives.
- Monolith: The rational choice for early-stage startups. A legitimate, defensible starting point
- Modular Monolith: The right choice when the team has grown to 10–50 people and the codebase needs structure. Preserves monolith-level development velocity while preparing for future service extraction
- Microservices: The right choice for large-scale, multi-team organizations. Should be adopted alongside — not before — team splits
- Serverless: Powerful for specific use cases (batch processing, event handling). Has meaningful constraints for always-on APIs
In investment and acquisition contexts, architectural evaluation matters because the choice reflects the organization’s capacity for intentional decision-making. “Is the architecture appropriate for the phase?” is one of the core questions in technical due diligence under system design evaluation.
Related Articles
Architecture choices are closely tied to cloud selection. The relationship between design patterns and infrastructure is explored in Cloud Services Explained: Reading AWS, GCP, and Azure as Business Decisions.
How architectural complexity converts into technical debt is covered in The Real Nature of Technical Debt: Patterns That Become Problems in Startups. For the full technical due diligence evaluation framework, see Technical Due Diligence: The Full Picture and Seven Evaluation Axes.
Tied Inc. provides technical due diligence support for VC firms and corporate M&A teams. For details on architecture evaluation and broader technical DD services, visit our investor services page or contact us.