When to use microservices (and when not to) - System Design Exercise

Design: Microservices Usage Decision Guide

Focus on decision criteria for choosing microservices vs monolithic architecture. Exclude detailed implementation or technology stack choices.

Functional Requirements

FR1: Identify scenarios where microservices architecture is beneficial

FR2: Identify scenarios where microservices architecture is not recommended

FR3: Explain trade-offs between microservices and monolithic architectures

FR4: Provide guidance on scalability, complexity, and team organization considerations

Non-Functional Requirements

NFR1: Recommendations must be practical and based on common industry experience

NFR2: Must consider system scale, team size, and operational complexity

NFR3: Must address latency and data consistency implications

NFR4: Must consider deployment and maintenance overhead

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Service boundaries and domain decomposition

API gateways and service discovery

Data management strategies (shared DB vs decentralized)

Deployment pipelines and automation

Monitoring and logging infrastructure

Design Patterns

Domain-Driven Design (DDD) for service boundaries

API Gateway pattern

Database per service pattern

Circuit Breaker and Bulkhead patterns for resilience

Event-driven communication and eventual consistency

Reference Architecture

Monolithic Architecture:
+-----------------------------+
|          Application        |
|  (All modules tightly bound) |
+-----------------------------+

Microservices Architecture:
+---------+   +---------+   +---------+
| Service |   | Service |   | Service |
|   A     |   |   B     |   |   C     |
+---------+   +---------+   +---------+
      |           |           |
      +-----------+-----------+
                  |
             API Gateway
                  |
             Clients/Users

Components

Monolithic Application

Any backend framework

Single deployable unit containing all business logic and data access

Microservices

Multiple independent services (e.g., Spring Boot, Node.js, Go)

Small, focused services each responsible for a specific business capability

API Gateway

Nginx, Kong, AWS API Gateway

Single entry point routing requests to appropriate microservices

Service Discovery

Consul, Eureka

Helps services find each other dynamically

Monitoring & Logging

Prometheus, ELK Stack

Track health and performance of services

Request Flow

1. Client sends request to API Gateway

2. API Gateway routes request to appropriate microservice based on URL or headers

3. Microservice processes request using its own database or data source

4. Microservice returns response to API Gateway

5. API Gateway returns response to client

Database Schema

Monolithic: Single database shared by all modules. Microservices: Each service owns its own database schema to ensure loose coupling and independent scaling.

Scaling Discussion

Bottlenecks

Monolithic app becomes hard to scale and maintain as codebase grows

Microservices add operational complexity and require mature DevOps

Data consistency challenges across distributed services

Increased network latency due to inter-service communication

Difficulty in debugging and tracing requests across services

Solutions

Start with monolith for small teams and simple apps, migrate to microservices as complexity grows

Invest in automation, monitoring, and CI/CD pipelines for microservices

Use eventual consistency and event-driven patterns to handle distributed data

Optimize communication with API Gateway and caching

Implement distributed tracing tools like OpenTelemetry

Interview Tips

Time: Spend first 10 minutes discussing system complexity and team size, next 15 minutes on pros and cons of microservices vs monolith, last 10 minutes on scaling challenges and operational considerations.

Microservices are best for large, complex systems with multiple teams

Monoliths are simpler and faster to develop for small projects

Microservices require investment in DevOps and monitoring

Trade-offs include scalability vs complexity and latency vs modularity

Clear domain boundaries help define microservice boundaries