Microservices vs Monolith

A team of 5 engineers building an early-stage product does not need microservices. A single deployable unit with a well-structured codebase is faster to build, simpler to debug, and cheaper to operate. Microservices become justified when the organization scales — multiple teams, independent release cadences, and workloads with vastly different scaling profiles. The architecture choice is driven by team structure and operational maturity, not by technology hype.

Monolith

A monolith is a single deployable unit where all functionality lives in one codebase, one build artifact, and one process (or a few replicas of it).

flowchart TB
    Client([Client]) --> LB[Load Balancer]
    LB --> M1[Monolith Instance 1]
    LB --> M2[Monolith Instance 2]
    LB --> M3[Monolith Instance 3]

    subgraph Monolith Instance
        direction TB
        API[API Layer]
        API --> Auth[Auth Module]
        API --> Orders[Order Module]
        API --> Payments[Payment Module]
        API --> Inventory[Inventory Module]
        Orders --> DB[(Single Database)]
        Payments --> DB
        Inventory --> DB
        Auth --> DB
    end

Benefits

When It Breaks Down

Microservices

Each business capability becomes an independently deployable service with its own codebase, database, and team.

flowchart TB
    Client([Client]) --> GW[API Gateway]

    GW --> Auth[Auth Service]
    GW --> Orders[Order Service]
    GW --> Payments[Payment Service]
    GW --> Inventory[Inventory Service]

    Auth --> AuthDB[(Auth DB)]
    Orders --> OrderDB[(Order DB)]
    Payments --> PayDB[(Payment DB)]
    Inventory --> InvDB[(Inventory DB)]

    Orders -->|async event| Payments
    Orders -->|async event| Inventory

Benefits

The Cost

The Distributed Monolith Anti-Pattern

The worst of both worlds: you split into services but they’re tightly coupled — shared databases, synchronous call chains, coordinated deployments.

flowchart LR
    A[Order Service] -->|sync HTTP| B[Payment Service]
    B -->|sync HTTP| C[Inventory Service]
    C -->|sync HTTP| D[Shipping Service]

    A --> DB[(Shared Database)]
    B --> DB
    C --> DB
    D --> DB

Symptoms:

• Deploying one service requires deploying others (they share schema)
• A single slow service cascades failures through the synchronous chain
• Teams can’t make schema changes without coordinating with every other team
• You have the operational cost of microservices with none of the benefits

Root cause: decomposition was done by technical layer (API layer, business logic layer, data layer) instead of business capability (order management, payments, inventory).

Decomposition Strategies

By Business Capability

Each service maps to a business function. The service owns the full vertical slice — API, logic, and data.

E-commerce platform:
├── Order Service         (create order, order status, order history)
├── Payment Service       (charge, refund, payment methods)
├── Inventory Service     (stock levels, reservations, replenishment)
├── Catalog Service       (products, pricing, categories)
├── User Service          (registration, profiles, authentication)
└── Notification Service  (email, push, SMS)

By DDD Bounded Context

Start with Domain-Driven Design: identify bounded contexts where terms have unambiguous meaning. An “Order” in the order context and a “Shipment” in the shipping context may refer to the same real-world event but have different data models and lifecycles.

Bounded Context: Order Management
  - Aggregate: Order (id, items, status, total)
  - Events: OrderPlaced, OrderCancelled
  - Own database, own team

Bounded Context: Shipping
  - Aggregate: Shipment (id, tracking_number, carrier, status)
  - Events: ShipmentCreated, ShipmentDelivered
  - Own database, own team

Communication: Order Management publishes OrderPlaced →
               Shipping consumes it and creates a Shipment

Decision Framework

The Modular Monolith Alternative

A middle ground: structure the monolith into well-encapsulated modules with strict boundaries — separate packages, no cross-module database queries, communication only through defined interfaces. When a module needs to become a service, it can be extracted with minimal refactoring.

monolith/
├── modules/
│   ├── orders/
│   │   ├── api/           (public API — other modules call this)
│   │   ├── internal/      (private — no other module imports this)
│   │   └── schema/        (own tables — other modules can't query directly)
│   ├── payments/
│   │   ├── api/
│   │   ├── internal/
│   │   └── schema/
│   └── inventory/
│       ├── api/
│       ├── internal/
│       └── schema/
└── shared/
    └── events/            (event bus for async communication between modules)

Shopify ran this pattern at enormous scale — a modular Rails monolith serving millions of merchants — before selectively extracting critical services.