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.