Monolith — The Single Deployable Unit - Monolith Vs Microservices Vs Modular Monolith | OneNoughtOne

0/273

System Design (HLD)Monolith vs Microservices vs Modular Monolith

Monolith vs Microservices vs Modular Monolith

LevelIntermediate

Duration75 mins

TopicMonolith vs Microservices vs Modular Monolith

1 / 5

Monolith — The Single Deployable Unit

The Architecture That Built the Internet

Before there were microservices, before service meshes and container orchestration, there was the monolith. Every major technology company you know today—Google, Amazon, Facebook, Netflix, Twitter—started with a monolithic architecture. Many billion-dollar products still run on monoliths. The monolith isn't a legacy pattern to be avoided; it's a foundational architectural approach with distinct advantages that, when applied correctly, can power systems serving millions of users.

In an industry obsessed with the new and novel, understanding the monolith deeply is essential. Not because it's outdated—far from it—but because recognizing when a monolith is the right choice separates pragmatic engineers from those who chase architectural trends without understanding trade-offs.

What You Will Learn

By the end of this page, you will understand what defines a monolithic architecture, its structural patterns, the genuine benefits it offers, the challenges it presents at scale, and—critically—when choosing a monolith is the smartest architectural decision you can make.

Defining the Monolith

A monolith is an architectural pattern where all components of an application—user interface handling, business logic, data access, and supporting services—are built, deployed, and run as a single unified unit. When you deploy the application, everything goes together. When you scale the application, you scale all of it together. When the application crashes, all of it goes down together.

This sounds limiting when stated bluntly, but this simplicity is precisely what makes monoliths powerful. There's no distributed coordination, no network boundaries between components, no service discovery, no independent versioning. One codebase, one deployment artifact, one running process (or a farm of identical processes).

The Etymology of 'Monolith'

The term comes from the Greek 'monolithos'—'mono' (single) + 'lithos' (stone). In architecture, a monolith is a large single upright block of stone. In software, it metaphorically represents an application carved from a 'single block' of code. The metaphor captures both the unity and the potential rigidity.

The Anatomy of a Monolith:

A typical monolithic application consists of several logical layers, all compiled into a single deployable artifact:

Presentation Layer — Handles HTTP requests, renders views, exposes APIs
Business Logic Layer — Contains domain models, services, rules, and workflows
Data Access Layer — Manages database connections, queries, ORM mappings
Cross-Cutting Concerns — Logging, authentication, authorization, caching

These layers exist as modules, packages, or namespaces within the codebase, but they compile together into one artifact—a JAR file, a .NET assembly, a bundled application, or a container image that contains everything.

Monolith Characteristics vs Distributed Systems
Characteristic	Monolith	Distributed System
Deployment unit	Single artifact (JAR, binary, container)	Multiple independent artifacts
Communication	In-process function calls	Network calls (HTTP, gRPC, messaging)
Data consistency	ACID transactions within single DB	Eventual consistency, distributed transactions
Failure domain	All-or-nothing	Partial failures possible
Scaling unit	Entire application	Individual services
Development model	Single codebase, shared language	Polyglot possible, multiple repos
Latency between components	Nanoseconds (memory access)	Milliseconds (network)

Structural Patterns Within Monoliths

Not all monoliths are created equal. The internal structure of a monolith dramatically affects its maintainability, testability, and evolvability. A well-structured monolith can evolve gracefully; a poorly structured one becomes the infamous 'Big Ball of Mud'—a tangled mess where every change risks breaking something unrelated.

Pattern 1: Layered (N-Tier) Monolith

The most common pattern organizes code into horizontal layers. Each layer has a specific responsibility and can only call the layer directly beneath it:

Controller/Presentation Layer → Handles HTTP, validates input
Service/Application Layer → Orchestrates use cases, coordinates domain objects
Domain/Business Layer → Contains business entities, rules, and logic
Repository/Data Access Layer → Abstracts database operations

This pattern provides clear separation of concerns but can lead to layers that just pass through data without adding value, creating unnecessary indirection.

Layered Monolith Pattern
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// Presentation Layer: Controllers handle HTTP
class OrderController {
    constructor(private orderService: OrderService) {}
    
    async createOrder(req: Request, res: Response) {
        const dto = validateOrderRequest(req.body);
        const order = await this.orderService.createOrder(dto);
        return res.status(201).json(order);
    }
}
 
// Application Layer: Services orchestrate use cases
class OrderService {
    constructor(
        private orderRepo: OrderRepository,
        private inventoryService: InventoryService,
        private paymentService: PaymentService
    ) {}
    
    async createOrder(dto: CreateOrderDTO): Promise<Order> {
        // Orchestrates multiple domain operations
        const items = await this.inventoryService.reserveItems(dto.items);
        const payment = await this.paymentService.authorize(dto.payment);
        const order = Order.create(dto.customerId, items, payment);
        return this.orderRepo.save(order);
    }
}
 
// Domain Layer: Business entities and rules
class Order {
    static create(customerId: string, items: OrderItem[], payment: Payment): Order {
        if (items.length === 0) throw new InvalidOrderError("Order must have items");
        if (payment.amount < Order.calculateTotal(items)) {
            throw new InsufficientPaymentError();
        }
        return new Order(generateId(), customerId, items, payment, 'PENDING');
    }
}
 
// Data Access Layer: Repository abstracts persistence
class OrderRepository {
    async save(order: Order): Promise<Order> {
        const record = await prisma.order.create({ 
            data: this.toDatabase(order) 
        });
        return this.toDomain(record);
    }
}

Pattern 2: Feature-Based (Vertical Slice) Monolith

Instead of organizing by technical layer, code is organized by feature or domain. Each feature folder contains everything needed for that feature—controllers, services, repositories, and domain models.

/src
  /orders
    orders.controller.ts
    orders.service.ts
    orders.repository.ts
    order.entity.ts
  /inventory
    inventory.controller.ts
    inventory.service.ts
    ...
  /payments
    ...

This pattern improves cohesion—related code lives together—and makes it easier to understand a feature in isolation. It also prepares the codebase for potential future extraction into services.

Pattern 3: Hexagonal (Ports and Adapters) Monolith

The hexagonal architecture places the domain at the center, surrounded by ports (interfaces) and adapters (implementations). External concerns—HTTP, databases, message queues—are treated as interchangeable adapters.

Domain Core — Pure business logic, no infrastructure dependencies
Ports — Interfaces defining how the domain interacts with the outside world
Adapters — Implementations of ports (HTTP adapter, PostgreSQL adapter, etc.)

This pattern enables excellent testability (the domain can be tested without infrastructure) and makes technology changes isolated to adapters.

Pattern 4: The Big Ball of Mud (Anti-Pattern)

The dreaded outcome when structure erodes over time. Symptoms include:

Direct database calls from controllers
Business logic scattered across layers
Circular dependencies between modules
Changes in one area cascading unpredictably
Fear of modification—nobody understands the impact

The Big Ball of Mud isn't a deliberate architecture; it's what happens when architecture is neglected under schedule pressure.

Structure Matters More Than Size

A 500,000-line monolith with clear boundaries and well-defined modules can be more maintainable than a 50,000-line codebase that's become a tangled mess. The key differentiator is discipline: enforcing boundaries, respecting layers, and refactoring ruthlessly.

The Genuine Benefits of Monoliths

In an era where microservices dominate conference talks and blog posts, monoliths are often portrayed exclusively in terms of their limitations. This is a profound mistake. Monolithic architectures offer genuine, substantial advantages that make them the right choice for many—perhaps most—applications.

Monolith Advantages

•Simplicity of Development — One codebase means one IDE project, one build system, one set of dependencies, one debugging environment. Developers can navigate from frontend to backend to database calls in a single jump. There's no need to understand service contracts, API versioning, or distributed debugging.
•Simplified Deployment — Deploy once, and everything updates. No coordination between services, no rolling deployments across multiple components, no concerns about version compatibility between services. CI/CD pipelines are straightforward—build, test, deploy.
•In-Process Communication — Function calls within a process are measured in nanoseconds. Service-to-service network calls are measured in milliseconds—a difference of 6 orders of magnitude. A workflow that would require 10 network hops in a microservices architecture requires zero in a monolith.
•ACID Transactions — Within a monolith backed by a single database, transactions are straightforward. Update the order, inventory, and payment records in one atomic transaction. In distributed systems, this requires complex saga patterns or two-phase commit.
•Simpler Testing — Integration tests can exercise the entire application in-process. No need to spin up multiple services, mock service dependencies, or deal with test environment networking. A single test database can verify end-to-end behavior.
•Easier Debugging — A single stack trace shows the complete call chain. Logging, profiling, and debugging happen in one process. Distributed tracing—essential in microservices—becomes unnecessary overhead.
•Lower Operational Complexity — One application to monitor, one set of alerts, one scaling configuration. No service mesh, no API gateway, no service discovery. The operational surface area is dramatically smaller.
•Refactoring Safety — Renaming a function, changing an interface, or restructuring modules is supported by IDE tooling. The compiler catches errors. In microservices, changing an API requires coordinating deployments across services.

Complexity Comparison: Monolith vs Microservices
Operational Concern	Monolith	Microservices
Services to deploy	1	10-100+
Network calls per request	0	5-20 (typical)
Transaction management	ACID (native)	Saga patterns (custom)
Debugging tools needed	Debugger, logs	Distributed tracing, correlation IDs
Testing effort for integration	Moderate	High (contract tests, service virtualization)
Deployment coordination	None	Version compatibility, rolling updates
Infrastructure components	App server, database	Service mesh, discovery, API gateway, message brokers

The Prime Directive of Simplicity

Simplicity is not the absence of capability—it's the presence of clarity. A monolith done well is a system where every developer can understand the full request flow, where debugging is straightforward, and where the cost of change is predictable. Don't underestimate these qualities.

The Genuine Challenges of Monoliths

For all their advantages, monoliths present real challenges—particularly as systems grow in size, traffic, and team complexity. Understanding these challenges honestly is essential for making informed architectural decisions.

Monolith Challenges

•Coupling Without Discipline — In a monolith, it's easy for one module to depend on the internals of another. Without rigorous boundary enforcement, dependencies become tangled, and the codebase evolves into a Big Ball of Mud.
•Scaling Limitations — You must scale the entire application, even if only one feature is under load. If your search functionality needs 10x capacity but order processing needs 1x, you're over-provisioning 90% of your compute for orders.
•Deployment Risk — Deploying the entire application means any bug affects the whole system. A regression in a minor feature can take down the entire application. Blast radius is maximum.
•Technology Lock-In — The entire application typically uses one language, one framework, one set of dependencies. Introducing a new technology requires migrating the entire codebase or accepting awkward integration.
•Build and Startup Time — Large monoliths compile and start slowly. A 10-minute build cycle and 2-minute startup time significantly impacts developer productivity and deployment frequency.
•Team Coordination Overhead — As the team grows, developers step on each other. Merge conflicts increase, shared code becomes contested, and coordinating releases becomes challenging.
•Database Bottlenecks — A single shared database becomes a scaling and organizational bottleneck. Schema changes affect the entire application, and database performance limits overall throughput.
•Partial Failure Impossible — If the monolith crashes, everything is unavailable. There's no graceful degradation where some features remain operational while others are down.

The Scaling Wall:

Monoliths often hit a 'scaling wall' where the limitations compound:

Traffic Scaling Wall — At some point, vertical scaling (bigger servers) reaches hardware limits, and horizontal scaling (more servers) is limited by database bottlenecks and state management.
Team Scaling Wall — Beyond roughly 10-15 developers working on the same codebase, coordination costs grow faster than productivity. Code reviews bottleneck on shared components, and the cognitive load of understanding the entire system exceeds capacity.
Release Scaling Wall — When you can only deploy the entire application, the risk of each deployment grows with the application size. Teams become hesitant to deploy, batching changes and increasing risk further.

Challenges ≠ Deal Breakers

Every architecture has challenges. The question is whether the challenges of a monolith are relevant to YOUR context. Many successful products at significant scale run on well-structured monoliths. The challenges only become critical at specific inflection points.

Famous Monoliths in Production

The notion that large-scale systems must use microservices is empirically false. Some of the most successful and heavily trafficked systems in the world run on monolithic architectures.

Large-Scale Monoliths in Production
Company	System	Scale	Architecture Note
Shopify	Core platform	~500M requests/min	Ruby on Rails monolith handling massive e-commerce traffic
Basecamp (DHH)	All products	Millions of users	Intentional monolith; creators of Ruby on Rails
Stack Overflow	Main site	~1.3B page views/month	C# monolith serving developer community
GitHub	github.com	100M+ developers	Long-running Ruby monolith (with some services)
Etsy	Marketplace	Billions in GMV	PHP monolith for core platform
Netlify	Core platform	Millions of sites	Go monolith handling deployments
Pinterest	Core platform	400M+ users	Django monolith for many years

The Stack Overflow Case Study:

Stack Overflow is particularly instructive. It serves over 1.3 billion page views per month with a relatively small team and a C# monolith. Their architecture approach emphasizes:

Vertical scaling to the maximum practical limit — Powerful servers handle enormous load
Aggressive caching — Multiple caching layers minimize database pressure
Careful performance optimization — Every millisecond is measured and optimized
Simplicity over distribution — Complexity is the enemy

Stack Overflow has proven that a well-optimized monolith can outperform many distributed systems at a fraction of the operational cost.

The Shopify Case Study:

Shopify's Ruby on Rails monolith handles extraordinarily high traffic, especially during events like Black Friday. Their approach involves:

Aggressive database sharding — Customer data is partitioned across many databases
Horizontal scaling of the monolith — Many identical instances behind load balancers
In-memory caching — Redis and Memcached reduce database load
Background job processing — Sidekiq handles asynchronous work

Shopify demonstrates that a monolith can scale to billions of dollars in transactions.

Real-World Validation

These examples demonstrate that the 'monoliths don't scale' narrative is a myth. Monoliths scale—if you understand your bottlenecks, optimize where it matters, and maintain architectural discipline. The architecture isn't the limiting factor; the engineering is.

When Monolith Is the Right Choice

Architecture decisions must be made in context. Here are the conditions where a monolithic architecture is likely the best choice:

Monolith-Favorable Conditions

•Early-Stage Products — When you're still discovering product-market fit, the last thing you need is distributed systems complexity. Build fast, iterate quickly, and worry about scaling when you have scaling problems.
•Small to Medium Teams (≤15 developers) — A team of 5-15 developers can effectively coordinate on a single codebase. The overhead of microservices doesn't pay off until teams are large enough to benefit from independent deployability.
•Uncertain Domain Boundaries — If you don't know where service boundaries should be, you'll draw them wrong. In a monolith, refactoring boundaries is a code change. In microservices, it requires re-architecting infrastructure.
•Strong Transactional Requirements — If your domain requires complex transactions spanning multiple entities (financial systems, inventory management), a monolith with ACID guarantees is far simpler than distributed saga patterns.
•Tight Performance Requirements — Sub-millisecond response times are easier to achieve without network hops between services. High-frequency trading, gaming servers, and real-time systems often favor monoliths.
•Limited Operational Capacity — If your team doesn't have dedicated DevOps expertise, operating a microservices fleet with service mesh, distributed tracing, and container orchestration may be beyond your capability.
•Stable Technology Stack — If you're committed to one technology ecosystem (Java/Spring, .NET, Ruby/Rails), there's no benefit from microservices' polyglot capability.
•Read-Heavy Workloads — Many applications are read-heavy and can scale effectively with caching, read replicas, and CDN—all compatible with monolithic architecture.

The Default Choice

Martin Fowler advocates for "Monolith First": start with a well-structured monolith, and only decompose into services when you have both the scale requirements AND the organizational needs that justify the added complexity. Most projects never reach that inflection point.

The Anti-Pattern: Premature Decomposition

One of the most common architectural mistakes is building microservices before you need them:

You don't know where boundaries should be
You pay distributed systems complexity tax from day one
You can't iterate on product as quickly
You need far more infrastructure expertise
Your debugging and testing are dramatically harder

"If you can't build a well-structured monolith, what makes you think you can build a well-structured distributed system?"

Distributed systems don't make bad designs better—they make them harder to fix.

Preparing a Monolith for Evolution

Building a monolith doesn't mean trapping yourself forever. With disciplined design, a monolith can evolve into a distributed system when—and if—that becomes necessary. The key is building internal boundaries that could become service boundaries later.

Practices That Enable Future Evolution

•Enforce Module Boundaries — Use language features (packages, modules, assemblies) to create hard boundaries. Modules should only communicate through well-defined interfaces, not by reaching into each other's internals.
•Design for Replaceability — Each major component should be replaceable without ripple effects. If swapping out the notification system would require changes in 50 files, your boundaries are leaking.
•Use Dependency Inversion — High-level modules shouldn't depend on low-level modules directly. Use interfaces/abstractions. This allows replacing implementations without changing callers.
•Minimize Shared State — The more modules share mutable state, the harder they are to separate. Each module should own its state and expose it through APIs.
•Database Table Ownership — Even with a shared database, define which module 'owns' each table. Only the owner should write to that table; others read through the owner's interface.
•Async Where Possible — Operations that could be asynchronous (sending emails, generating reports, updating caches) should use a job queue. This pattern translates directly to cross-service messaging later.
•API-First Internal Boundaries — Major modules should expose internal APIs that look like service APIs. If the order module had to become an order service, would its interface change? If yes, refactor now.

Evolution-Ready Boundary Design
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// Bad: Direct coupling between modules
// If we extract OrderModule, this breaks
class ShippingService {
    calculateRate(orderId: string) {
        // Directly accesses internal order details
        const order = OrderRepository.findById(orderId);
        const items = order.items.map(i => 
            InventoryRepository.getWeight(i.productId)
        );
        return this.computeRate(order.address, items);
    }
}
 
// Good: Interface-based coupling (evolution-ready)
// ShippingModule defines what it needs from Orders
interface OrderShippingDetails {
    orderId: string;
    destinationAddress: Address;
    items: Array<{ weight: number; dimensions: Dimensions }>;
}
 
// OrderModule exposes a well-defined interface
interface OrderModulePort {
    getShippingDetails(orderId: string): Promise<OrderShippingDetails>;
}
 
// ShippingModule depends on abstraction, not implementation
class ShippingService {
    constructor(private orderModule: OrderModulePort) {}
    
    async calculateRate(orderId: string) {
        // If OrderModule becomes a service, this interface stays the same
        // Only the implementation of OrderModulePort changes (HTTP calls instead of direct)
        const details = await this.orderModule.getShippingDetails(orderId);
        return this.computeRate(details.destinationAddress, details.items);
    }
}

The Strangler Fig Pattern

When it's time to decompose, you don't rewrite from scratch. The Strangler Fig pattern gradually routes traffic from the monolith to new services, one slice at a time. Well-defined internal boundaries make this process incremental and reversible.

Summary: The Monolith's Place in Modern Architecture

We've explored the monolithic architecture in depth—not as an outdated pattern to avoid, but as a legitimate and often optimal choice for building software systems.

Key Takeaways

•Monoliths are single deployable units — All components compile, deploy, and run together, with in-process communication measured in nanoseconds.
•Structure matters more than size — A well-structured 500K-line monolith outperforms a tangled 50K-line codebase. Enforce boundaries with discipline.
•Genuine advantages exist — Simplicity of development, deployment, testing, debugging, and operations. ACID transactions without saga complexity. No distributed systems overhead.
•Genuine challenges exist — Coupling risk, scaling inflexibility, technology lock-in, team coordination overhead. These become critical at specific inflection points.
•Many successful products run on monoliths — Shopify, Stack Overflow, GitHub, Basecamp—scale doesn't require microservices.
•Monolith is often the right default — 'Monolith First' makes sense for early-stage products, small teams, uncertain domains, and tight performance requirements.
•Design for evolvability — Build internal boundaries as if they could become service boundaries. Use interfaces, minimize coupling, own your data.

What's Next:

Now that we understand monolithic architecture deeply, we'll explore the other end of the spectrum: microservices. The next page examines independent services—their promise, their reality, and the organizational and technical prerequisites for success.

Page Complete

You now understand monolithic architecture at a depth that transcends surface-level criticism. You can articulate when monoliths are appropriate, how to structure them well, and how to prepare for future evolution. Next, we explore microservices—and why the grass isn't always greener on the distributed side.