Part 27: Monolith vs Microservices Delivery Architecture

Introduction — The Most Debated Architectural Decision

"Should we use microservices?" is the question that launched a thousand conference talks, blog posts, and architectural arguments. For nearly a decade, "microservices" was synonymous with "modern" and "monolith" was synonymous with "legacy." But the industry is waking up to a more nuanced reality: architecture is a tradeoff, not a progression.

This article examines monoliths, modular monoliths, and microservices through the lens that matters most for this series: delivery. How does each architecture affect your ability to build, test, deploy, and operate software? What does each demand from your CI/CD pipelines, team structure, and observability?

The Pendulum Swings Back

The industry has gone through a clear cycle:

1. 2005-2012: Large monoliths dominate. Companies like Amazon, Netflix, and eBay struggle with deployment speed.
2. 2012-2018: Microservices revolution. Netflix, Uber, and Spotify evangelise the approach. Everyone wants to "do microservices."
3. 2018-2023: Reality hits. Teams discover the "distributed systems tax." Many find they traded monolith problems for worse distributed problems.
4. 2023-present: Nuance prevails. "Modular monolith" emerges as a middle ground. Amazon Prime Video famously moves back from microservices to a monolith for one service, reducing costs by 90%.

The Monolith

A monolith is a single deployable unit containing all application functionality. One codebase, one build process, one deployment artifact. When you deploy, you deploy everything.

Types of Monoliths

When Monoliths Win

Monoliths have significant advantages that are often overlooked in the microservices hype:

• Simple deployment — One artifact, one pipeline, one deploy. No service coordination required.
• Easy debugging — Stack traces show the full call path. No distributed tracing needed.
• No network calls between components — In-process function calls are millions of times faster than HTTP/gRPC.
• Simple transactions — ACID transactions across the entire application. No saga patterns needed.
• Lower operational overhead — One service to monitor, one set of logs, one scaling strategy.
• Faster development for small teams — No service contracts, no API versioning, no service discovery.

# Monolith deployment: one command
docker build -t myapp:v2.3.1 .
docker push registry.example.com/myapp:v2.3.1
kubectl set image deployment/myapp myapp=registry.example.com/myapp:v2.3.1

# That's it. One image, one deployment, one rollback target.

The Modular Monolith

A modular monolith is a single deployable unit with well-defined internal module boundaries. Each module owns a specific domain, has a clear public API, and cannot access the internals of other modules. Think of it as microservices within a single process.

# Modular monolith structure
src/
├── modules/
│   ├── orders/
│   │   ├── api/          # Public interface (what other modules can call)
│   │   ├── domain/       # Business logic (private)
│   │   ├── persistence/  # Database access (private)
│   │   └── events/       # Domain events published
│   ├── payments/
│   │   ├── api/
│   │   ├── domain/
│   │   ├── persistence/
│   │   └── events/
│   ├── inventory/
│   │   ├── api/
│   │   ├── domain/
│   │   ├── persistence/
│   │   └── events/
│   └── shipping/
│       ├── api/
│       ├── domain/
│       ├── persistence/
│       └── events/
├── shared/               # Shared kernel (minimal)
└── main.py               # Single entry point

The key rules of a modular monolith:

• Modules communicate only through public APIs — no reaching into another module's database tables or internal classes.
• Each module owns its data — separate schemas or separate tables with no cross-module joins.
• Modules publish domain events — async communication between modules via an in-process event bus.
• Compilation/linting enforces boundaries — tools like ArchUnit (Java), Packwerk (Ruby), or custom lint rules prevent violations.

Shopify's Modular Monolith

Shopify is the most prominent example of a modular monolith at scale. Their Ruby on Rails monolith serves millions of merchants and processes billions in transactions. Rather than decomposing into microservices, they invested in Packwerk — a tool that enforces module boundaries at the code level.

Microservices

Microservices are independently deployable services, each owning a specific business capability. Each service has its own codebase, its own deployment pipeline, its own data store, and can be written in different programming languages.

Benefits When Done Right

• Independent deployment — Change one service without touching others. Deploy 50 times a day if needed.
• Independent scaling — Scale the payment service to 100 instances while keeping the admin panel at 2.
• Technology diversity — Use Python for ML services, Go for high-performance APIs, Node.js for real-time features.
• Fault isolation — If the recommendation service crashes, checkout still works.
• Team autonomy — Teams own services end-to-end. No coordinated releases needed.

The Distributed Systems Tax

Every benefit of microservices comes with a corresponding cost — the "distributed systems tax" you pay regardless of whether you need the benefit:

Distributed Systems Challenges

The Eight Fallacies of Distributed Computing

In 1994, Peter Deutsch identified eight assumptions that developers make about networks — all of which are false:

1. The network is reliable — Packets get lost. Connections drop. Cables get cut.
2. Latency is zero — Every network call adds milliseconds. 50 service calls = 50× the latency.
3. Bandwidth is infinite — Serialisation overhead, payload sizes, and congestion are real.
4. The network is secure — Every service-to-service call is an attack surface.
5. Topology does not change — Services move, IPs change, instances scale up and down.
6. There is one administrator — Different teams own different services with different policies.
7. Transport cost is zero — Serialisation/deserialisation, TLS handshakes, DNS lookups all cost CPU.
8. The network is homogeneous — Different protocols, versions, and configurations across services.

The Saga Pattern — Distributed Transactions

In a monolith, you wrap a business operation in a database transaction: either everything succeeds or everything rolls back. In microservices, this is impossible — each service owns its own database. The Saga pattern provides eventual consistency through a series of local transactions with compensating actions:

sequenceDiagram
    participant O as Order Service
    participant P as Payment Service
    participant I as Inventory Service
    participant S as Shipping Service
    
    O->>O: Create Order (PENDING)
    O->>P: Reserve Payment
    P-->>O: Payment Reserved
    O->>I: Reserve Inventory
    I-->>O: Inventory Reserved
    O->>S: Schedule Shipping
    S-->>O: Shipping Scheduled
    O->>O: Mark Order CONFIRMED
    
    Note over O,S: If any step fails...
    O->>S: Cancel Shipping (compensate)
    O->>I: Release Inventory (compensate)
    O->>P: Release Payment (compensate)
    O->>O: Mark Order FAILED
                            

Conway's Law

"Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure." — Melvin Conway, 1967

This is not just an observation — it is a force of nature in software engineering. If you have three teams, you will end up with three services (or three modules) regardless of what the architecture diagram says. Conway's Law has profound implications for architecture decisions:

• Small team (5-8 people)? → A monolith matches your communication structure perfectly. You all talk to each other daily anyway.
• Multiple teams (20+ people)? → Microservices align with team boundaries. Each team owns a service.
• Inverse Conway Maneuver → Deliberately structure your teams to produce the architecture you want. Want three microservices? Create three teams.

Service Mesh

A service mesh is an infrastructure layer for service-to-service communication. It provides traffic management, security (mTLS), and observability without requiring changes to application code. The mesh works by deploying a sidecar proxy alongside each service instance.

flowchart LR
    subgraph Pod A
        A[Service A] --> PA[Proxy A]
    end
    subgraph Pod B
        PB[Proxy B] --> B[Service B]
    end
    subgraph Pod C
        PC[Proxy C] --> C[Service C]
    end
    subgraph Control Plane
        CP[Mesh Controller]
    end
    
    PA -->|mTLS| PB
    PA -->|mTLS| PC
    CP -->|Config| PA
    CP -->|Config| PB
    CP -->|Config| PC
                            

Major service mesh implementations:

Decomposition Strategies

When you decide to break a monolith apart, how you decompose matters enormously. Do it wrong and you get a "distributed monolith" — the worst of both worlds.

The Strangler Fig Pattern

Named after strangler fig trees that gradually envelop their host, this pattern lets you incrementally replace monolith functionality with new services:

flowchart TD
    subgraph Phase 1
        LB1[Load Balancer] --> M1[Monolith
Handles Everything]
    end
    
    subgraph Phase 2
        LB2[Load Balancer] --> M2[Monolith
Most Features]
        LB2 --> S1[New Service
Orders]
    end
    
    subgraph Phase 3
        LB3[Load Balancer] --> M3[Monolith
Legacy Only]
        LB3 --> S2[Orders Service]
        LB3 --> S3[Payments Service]
        LB3 --> S4[Users Service]
    end
                            

Key decomposition strategies:

• Strangler Fig — Route traffic to new service for specific paths. Gradually move functionality until the monolith is empty.
• Domain-Driven Decomposition — Identify bounded contexts using DDD. Each bounded context becomes a service candidate.
• Event Storming — Workshop technique to discover domain events, aggregates, and bounded contexts. Excellent for finding natural service boundaries.
• Database Seam — Find tables that are accessed by only one part of the codebase. Extract that code and those tables into a service.

Delivery Implications

Your architecture fundamentally shapes your delivery process. Here is a direct comparison:

When to Choose What

There is no universal "best" architecture. The right choice depends on your context:

flowchart TD
    A[New Project?] --> B{Team Size?}
    B -->|1-8 engineers| C{Product Maturity?}
    B -->|8-30 engineers| D{Clear Domain Boundaries?}
    B -->|30+ engineers| E[Microservices likely appropriate]
    
    C -->|Early/MVP| F[Start with Monolith]
    C -->|Mature/Scaling| G[Modular Monolith]
    
    D -->|Yes| H{CI/CD + Observability mature?}
    D -->|No| G
    
    H -->|Yes| I[Consider Microservices]
    H -->|No| G
    
    F --> J[Evolve when pain appears]
    G --> K[Extract services only when justified]
                            

Exercises

Conclusion & Next Steps

The monolith vs microservices debate is not about which is "better" — it is about which fits your context. A monolith is not legacy; microservices are not modern. Both are tools with tradeoffs. The modular monolith offers a compelling middle ground that gives you module boundaries and team ownership without the operational tax of distribution.

The most important takeaway: architecture should follow team structure and delivery capability. If you do not have CI/CD maturity, observability, and team autonomy, microservices will make everything harder, not easier. Build the delivery foundations first (Parts 1-26 of this series), then let your architecture evolve to match your growing capabilities.

In Part 28: Release Architecture & Multi-Environment Systems, we will explore how software moves through multiple environments — from developer laptops through staging to production — and how to design promotion pipelines, manage environment parity, and handle configuration across environments.