Monolith vs microservices comparison - Design Approaches Compared

Design: Monolith vs Microservices Architecture Comparison

Compare two architectural styles for the same application: a monolithic design and a microservices design. Focus on design, deployment, scaling, and maintenance aspects. Out of scope: detailed UI design, specific programming languages.

Functional Requirements

FR1: Support a web application with user authentication, product catalog, order processing, and payment handling

FR2: Allow easy deployment and updates without downtime

FR3: Enable independent scaling of different parts of the system

FR4: Ensure data consistency and reliability

FR5: Provide clear monitoring and error tracking

Non-Functional Requirements

NFR1: Handle 10,000 concurrent users

NFR2: API response time p99 under 300ms

NFR3: Availability target 99.9% uptime

NFR4: Support continuous deployment with minimal risk

NFR5: Maintain data integrity across services

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

User authentication module

Product catalog management

Order processing system

Payment gateway integration

Database(s) and caching layer

API gateway or load balancer

Monitoring and logging tools

Design Patterns

Single deployable unit vs multiple deployable services

Database per service vs shared database

Synchronous REST API calls vs asynchronous messaging

Circuit breaker and fallback mechanisms

Service discovery and load balancing

Reference Architecture

Monolith Architecture:

+-----------------------------+
|        Web Server           |
|  (Handles all requests)     |
|                             |
| +-------------------------+ |
| | Authentication Module    | |
| +-------------------------+ |
| +-------------------------+ |
| | Product Catalog Module   | |
| +-------------------------+ |
| +-------------------------+ |
| | Order Processing Module  | |
| +-------------------------+ |
| +-------------------------+ |
| | Payment Module           | |
| +-------------------------+ |
| +-------------------------+ |
| | Shared Database          | |
| +-------------------------+ |
+-----------------------------+

Microservices Architecture:

+----------------+       +----------------+       +----------------+
| Auth Service   |<----->| API Gateway    |<----->| Product Service |
+----------------+       +----------------+       +----------------+
       |                                              |
       v                                              v
+----------------+                             +----------------+
| Order Service  |                             | Payment Service|
+----------------+                             +----------------+
       |                                              |
       v                                              v
+----------------+                             +----------------+
| Auth DB       |                             | Payment DB     |
+----------------+                             +----------------+

Each service has its own database and communicates via API Gateway.

Components

Web Server (Monolith)

Node.js / Java / Python

Handles all application logic and serves all modules in one deployable unit

Authentication Service

Spring Boot / Express.js microservice

Manages user login, registration, and session management

Product Service

Microservice with REST API

Manages product catalog data and queries

Order Service

Microservice with REST API

Handles order creation, updates, and status tracking

Payment Service

Microservice integrating payment gateway

Processes payments and manages payment status

API Gateway

Nginx / Kong / AWS API Gateway

Routes client requests to appropriate microservices, handles authentication and rate limiting

Databases

Relational DB (PostgreSQL) for monolith; separate DBs per microservice

Stores persistent data for each module or service

Monitoring and Logging

Prometheus, Grafana, ELK Stack

Tracks system health, logs errors, and monitors performance

Request Flow

1. User sends request to web server (monolith) or API Gateway (microservices).

2. In monolith, web server processes request internally calling modules directly.

3. In microservices, API Gateway routes request to appropriate service based on URL and method.

4. Service processes request, accesses its own database, and returns response.

5. API Gateway aggregates responses if needed and sends back to user.

6. For writes affecting multiple services, microservices coordinate via events or API calls ensuring eventual consistency.

7. Monitoring tools collect metrics and logs from all components.

Database Schema

Entities: - User (id, name, email, password_hash) - Product (id, name, description, price, stock) - Order (id, user_id, status, total_amount, created_at) - Payment (id, order_id, status, payment_method, amount, processed_at) Relationships: - User 1:N Order - Order 1:1 Payment - Product N:M Order (through OrderItems junction table) In monolith: all entities in one shared database. In microservices: each service owns its database; e.g., Auth Service owns User table, Product Service owns Product table, Order Service owns Order and OrderItems, Payment Service owns Payment table.

Scaling Discussion

Bottlenecks

Monolith: Entire application must scale together, leading to resource waste.

Monolith: Deployment requires full system downtime or complex blue-green deployments.

Microservices: Network latency and failures between services can increase response time.

Microservices: Data consistency is harder due to distributed databases.

Microservices: Increased operational complexity with many services to monitor and maintain.

Solutions

Monolith: Use load balancers and replicate instances to handle more users; consider modularizing codebase.

Monolith: Implement zero-downtime deployment strategies like blue-green or canary releases.

Microservices: Use asynchronous messaging and circuit breakers to reduce latency impact and improve resilience.

Microservices: Implement eventual consistency patterns and distributed transactions carefully.

Microservices: Use centralized logging, monitoring, and orchestration tools (e.g., Kubernetes) to manage complexity.

Interview Tips

Time: Spend 10 minutes explaining monolith design and pros/cons, 15 minutes on microservices design and challenges, 10 minutes comparing both and discussing scaling, 10 minutes answering questions.

Explain how monolith is simpler to develop and deploy initially but harder to scale and maintain as system grows.

Describe microservices benefits: independent deployment, scaling, and technology diversity.

Discuss trade-offs: complexity, data consistency, and operational overhead in microservices.

Highlight importance of choosing architecture based on team size, application complexity, and business needs.

Mention real-world examples and best practices for both architectures.

Practice

1. Which of the following best describes a monolithic architecture?

easy

A. Many small independent services communicating over a network

B. A database optimized for distributed transactions

C. A cloud service that automatically scales resources

D. A single large application where all components are tightly integrated

Solution

1. Step 1: Understand monolithic architecture

   A monolithic architecture means all parts of the application are combined into one single unit.

2. Step 2: Compare with other options

   Many small independent services communicating over a network describes microservices, C cloud scaling, and D databases, not monoliths.

3. Final Answer:

   A single large application where all components are tightly integrated -> Option D

4. Quick Check:

   Monolith = single big app [OK]

Hint: Monolith = one big app, microservices = many small apps [OK]

Common Mistakes:

• Confusing microservices with monolith
• Thinking monolith means cloud scaling
• Mixing database types with architecture

2. Which syntax correctly describes a microservice in a system design diagram?

easy

A. Multiple boxes each labeled with a specific service name

B. A single box labeled 'App' containing all modules

C. A database icon connected to a single app box

D. A cloud icon with no internal components

Solution

1. Step 1: Identify microservice representation

   Microservices are shown as multiple small boxes, each representing a service.

2. Step 2: Eliminate incorrect options

   A single box labeled 'App' containing all modules shows a monolith, C shows database relation, D is too vague.

3. Final Answer:

   Multiple boxes each labeled with a specific service name -> Option A

4. Quick Check:

   Microservices = many small boxes [OK]

Hint: Microservices = many small boxes, monolith = one big box [OK]

Common Mistakes:

• Choosing single box for microservices
• Confusing database icons with services
• Ignoring service labels

3. Given a system with a monolithic app and a microservices app, which scenario shows better scaling for microservices?

medium

A. Scaling the entire monolith when only one feature needs more resources

B. Scaling only the specific microservice that handles the busy feature

C. Scaling the database only in the monolith

D. Scaling the user interface layer in the monolith

Solution

1. Step 1: Understand scaling in monolith vs microservices

   Monolith requires scaling the whole app, microservices allow scaling individual services.

2. Step 2: Identify the efficient scaling method

   Scaling only the busy microservice is more efficient and flexible than scaling the entire monolith.

3. Final Answer:

   Scaling only the specific microservice that handles the busy feature -> Option B

4. Quick Check:

   Microservices scale individual parts [OK]

Hint: Microservices scale parts; monolith scales whole app [OK]

Common Mistakes:

• Thinking monolith scales parts independently
• Confusing database scaling with app scaling
• Ignoring microservice granularity

4. A team tries to split a monolithic app into microservices but faces frequent communication failures. What is the most likely cause?

medium

A. They deployed all microservices on the same server

B. They used a single database for all microservices

C. They did not implement proper API contracts between services

D. They kept all code in one repository

Solution

1. Step 1: Identify communication needs in microservices

   Microservices communicate over APIs; clear contracts are essential to avoid failures.

2. Step 2: Analyze other options

   Using a single database or same server is possible but less likely to cause communication failures; code repo does not affect runtime communication.

3. Final Answer:

   They did not implement proper API contracts between services -> Option C

4. Quick Check:

   API contracts prevent communication failures [OK]

Hint: API contracts are key for microservice communication [OK]

Common Mistakes:

• Blaming database sharing for communication errors
• Assuming deployment location causes failures
• Confusing code repo structure with runtime issues

5. A startup plans to build a new product with a small team and expects rapid changes. Which architecture is best and why?

hard

A. Monolith, because it is simpler to develop and deploy quickly

B. Microservices, because it allows independent scaling from day one

C. Monolith, because it supports multiple databases easily

D. Microservices, because it requires fewer resources initially

Solution

1. Step 1: Consider team size and speed needs

   A small team with rapid changes benefits from simpler, faster development and deployment.

2. Step 2: Evaluate architecture fit

   Monolith is simpler to build and deploy quickly; microservices add complexity and overhead not ideal for small teams initially.

3. Final Answer:

   Monolith, because it is simpler to develop and deploy quickly -> Option A

4. Quick Check:

   Small team + fast changes = monolith [OK]

Hint: Small teams start monolith for speed, microservices add complexity [OK]

Common Mistakes:

• Choosing microservices for small teams without need
• Assuming microservices always scale better initially
• Ignoring development speed and team skills