DEV Community

Jaspreet singh
Jaspreet singh

Posted on

HLD Fundamentals #3: Monolithic vs Microservices Architecture

#architecture #microservices #softwareengineering #systemdesign

As applications grow, one of the biggest architectural decisions is whether to keep everything in a single application (Monolith) or split it into independent services (Microservices).

Most startups begin as a Monolith and gradually move toward Microservices as scale, team size, and business complexity increase.

Monolithic Architecture

What is it?

A Monolithic Architecture is a single application where all business functionalities are developed, deployed, and managed together.

Everything runs inside one codebase and one deployment unit.

How Does It Work? 

                    Monolithic Application

    +---------------------------------------------------+
    |                                                   |
    |  User Service                                     |
    |  Product Service                                  |
    |  Order Service                                    |
    |  Payment Service                                  |
    |  Notification Service                             |
    |                                                   |
    +---------------------------------------------------+

                        |
                        V

                  Single Database
Enter fullscreen mode Exit fullscreen mode

All modules share:

  • Same codebase
  • Same deployment
  • Usually same database

Real World Example

Early Amazon

Initially Amazon was a large monolithic application.

Features like:

  • Product Catalog
  • Orders
  • Payments
  • Shipping

were all part of the same application.

Advantages

Easy Development

Everything is in one place.

Developers can easily navigate the codebase.

Easy Deployment

Only one application needs deployment.

Simpler Testing

End-to-end testing is easier.

Lower Initial Cost

Perfect for startups and MVPs.

Disadvantages

Difficult Scaling

If only Order Service requires scaling:

Entire Application
must be scaled
Enter fullscreen mode Exit fullscreen mode

Slower Deployments

Small changes require deploying the entire application.

Large Codebase

As features grow:

100k+ lines
500k+ lines
Millions of lines
Enter fullscreen mode Exit fullscreen mode

maintenance becomes difficult.

Single Point of Failure

One issue can impact the entire system.

Interview One-Liner

A Monolithic Architecture packages all business functionalities into a single deployable application.

Microservices Architecture

What is it?

Microservices Architecture breaks an application into multiple independent services.

Each service:

  • Owns a specific business capability
  • Has its own deployment lifecycle
  • Can scale independently

How Does It Work? 

                    Client
                       |
                       V

                 API Gateway
                       |
    ------------------------------------------------
    |                |               |             |
    V                V               V             V

 User Service   Order Service   Payment Service   Product Service

    |                |               |             |
    V                V               V             V

 User DB       Order DB      Payment DB     Product DB
Enter fullscreen mode Exit fullscreen mode

Each service is responsible for its own business domain.

Real World Example

Netflix

Netflix has hundreds of microservices.

Examples:

  • Recommendation Service
  • User Service
  • Billing Service
  • Streaming Service
  • Search Service

Each service can scale independently.

Advantages

Independent Deployment

Deploy one service without touching others.

Independent Scaling

Scale only the services experiencing heavy traffic.

Better Fault Isolation

If Recommendation Service fails:

Video Streaming
still works
Enter fullscreen mode Exit fullscreen mode

Technology Flexibility

Different services can use different technologies.

Java
Go
Node.js
Python
Enter fullscreen mode Exit fullscreen mode

Disadvantages

Increased Complexity

Managing many services is harder.

Network Calls

Communication happens over network.

Service A -> Service B
Enter fullscreen mode Exit fullscreen mode

which introduces latency.

Distributed Data Challenges

Maintaining consistency becomes difficult.

DevOps Overhead

Requires:

  • Monitoring
  • Logging
  • Service Discovery
  • API Gateway
  • Container Orchestration

Interview One-Liner

Microservices Architecture divides an application into independently deployable services organized around business capabilities.

Evolution Towards Microservices

Most companies follow these phases.

Phase 1: Monolith 

Users
  |
  V

Monolithic Application
        |
        V
    Database
Enter fullscreen mode Exit fullscreen mode

Best for:

  • MVPs
  • Early startups

Phase 2: Modular Monolith

Application remains one deployment but code is separated into modules.

Application

├── User Module
├── Product Module
├── Order Module
└── Payment Module
Enter fullscreen mode Exit fullscreen mode

This prepares the system for future extraction.

Phase 3: Service Extraction

Frequently changing modules are extracted first.

Monolith

      |
      |
      +----> Payment Service
Enter fullscreen mode Exit fullscreen mode

Common candidates:

  • Authentication
  • Notifications
  • Payments

Phase 4: Hybrid Architecture

Some functionality remains in monolith.

Some functionality becomes microservices.

Monolith
   |
   +---- User Service
   |
   +---- Payment Service
Enter fullscreen mode Exit fullscreen mode

This stage is common in growing companies.

Phase 5: Full Microservices 

User Service
Order Service
Payment Service
Inventory Service
Notification Service
Enter fullscreen mode Exit fullscreen mode

All services operate independently.

Interview One-Liner

Most organizations migrate gradually from Monolith → Modular Monolith → Hybrid Architecture → Microservices.

Decomposition Patterns

What is Decomposition?

Decomposition is the process of breaking a large monolithic application into smaller services.

This is one of the most important topics in Microservices interviews.

1. Decompose by Business Capability

Services are created around business functions.

Example: E-Commerce 

E-Commerce System

├── User Service
├── Product Service
├── Cart Service
├── Order Service
├── Payment Service
└── Notification Service
Enter fullscreen mode Exit fullscreen mode

Each service owns a business capability.

Why It Works?

Teams align with business domains.

Order Team
Product Team
Payment Team
Enter fullscreen mode Exit fullscreen mode

Each team owns its service.

Most Common Pattern

This is the preferred decomposition strategy.

Large companies use this approach extensively.

Real Example

Amazon

Catalog Service
Checkout Service
Payment Service
Inventory Service
Enter fullscreen mode Exit fullscreen mode

Each service represents a business capability.

Interview One-Liner

Business Capability decomposition organizes services around business functions rather than technical layers.

2. Decompose by Subdomain (DDD)

Based on Domain Driven Design.

Business is divided into bounded contexts.

Example: Banking 

Banking System

├── Customer Domain
├── Account Domain
├── Loan Domain
├── Card Domain
└── Payment Domain
Enter fullscreen mode Exit fullscreen mode

Each domain becomes an independent service.

Benefits

  • Clear ownership
  • Strong boundaries
  • Better maintainability

Interview One-Liner

Domain decomposition creates services around bounded business domains and is commonly used with Domain Driven Design.

3. Decompose by Resource

Services are organized around resources.

Example 

User Resource
Product Resource
Order Resource
Enter fullscreen mode Exit fullscreen mode

becomes

User Service
Product Service
Order Service
Enter fullscreen mode Exit fullscreen mode

This works well for CRUD-heavy systems.

Interview One-Liner

Resource-based decomposition creates services around core business entities.

4. Strangler Pattern

One of the most important migration patterns.

Instead of rewriting the entire monolith:

  • Extract one service at a time
  • Route traffic gradually
  • Replace old functionality slowly

Example 

              Client
                 |
                 V

            API Gateway
                 |
       ---------------------
       |                   |
       V                   V

   Monolith         Payment Service
Enter fullscreen mode Exit fullscreen mode

Later:

Payment Service
User Service
Order Service
Enter fullscreen mode Exit fullscreen mode

continue replacing monolith functionality.

Why Companies Use It?

Large applications cannot be rewritten overnight.

Netflix, Amazon, and many enterprises use gradual migration.

Interview One-Liner

The Strangler Pattern gradually replaces parts of a monolith with microservices without requiring a full rewrite.

Monolith vs Microservices

Feature Monolith Microservices
Deployment Single Multiple
Scalability Whole App Per Service
Complexity Low High
Development Speed Faster Initially Slower Initially
Fault Isolation Poor Better
Team Independence Limited High
Technology Flexibility Low High
Operational Overhead Low High

When Should You Use Monolith?

Use Monolith when:

  • Startup or MVP
  • Small team
  • Limited traffic
  • Fast delivery required

When Should You Use Microservices?

Use Microservices when:

  • Large engineering teams
  • Millions of users
  • Independent deployments required
  • Different scaling requirements exist

Quick Revision

Monolith 

One Application
One Deployment
Usually One Database
Enter fullscreen mode Exit fullscreen mode

Microservices 

Many Services
Independent Deployments
Independent Scaling
Enter fullscreen mode Exit fullscreen mode

Migration Path 

Monolith
    ↓
Modular Monolith
    ↓
Hybrid Architecture
    ↓
Microservices
Enter fullscreen mode Exit fullscreen mode

Important Decomposition Patterns 

Business Capability
Domain Driven Design
Resource Based
Strangler Pattern
Enter fullscreen mode Exit fullscreen mode

Interview Summary

Monolithic architecture is simple, easy to develop, and ideal for startups, but becomes difficult to scale and maintain as systems grow. Microservices solve these problems by breaking applications into independently deployable services. The most common decomposition strategy is by business capability, while the Strangler Pattern is widely used to migrate gradually from a monolith to microservices without a complete rewrite.

Top comments (0)