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

Practice

1. Which scenario is best suited for using microservices architecture?

easy

A. A large, complex application requiring independent scaling of components

B. A simple, single-function app with a small user base

C. A small script running on a single machine

D. A static website with no backend logic

Solution

1. Step 1: Understand microservices purpose

   Microservices are designed for complex apps where parts can scale or update independently.

2. Step 2: Match scenario to microservices benefits

   A large app needing flexibility and scaling fits microservices well; small or simple apps do not.

3. Final Answer:

   A large, complex application requiring independent scaling of components -> Option A

4. Quick Check:

   Complex app = microservices [OK]

Hint: Use microservices only for complex, scalable apps [OK]

Common Mistakes:

• Choosing microservices for small or simple apps
• Ignoring team size and management overhead
• Assuming microservices always improve performance

2. Which of the following is a correct reason NOT to use microservices?

easy

A. The app requires frequent updates to parts

B. The application is very small and simple

C. The app needs to scale independently

D. The app has multiple teams working on different features

Solution

1. Step 1: Identify when microservices are unnecessary

   Microservices add complexity and overhead, so small simple apps don't benefit.

2. Step 2: Evaluate options

   Options A, B, and D are reasons to use microservices, not avoid them.

3. Final Answer:

   The application is very small and simple -> Option B

4. Quick Check:

   Small app = avoid microservices [OK]

Hint: Avoid microservices for small, simple apps [OK]

Common Mistakes:

• Confusing scaling needs as a reason to avoid microservices
• Ignoring complexity added by microservices
• Assuming microservices fit all team sizes

3. Consider a microservices app with 5 services. If each service requires 2 developers and the team has only 6 developers total, what is the likely outcome?

medium

A. The team can easily manage all services independently

B. The services will merge into a monolith automatically

C. The team will struggle due to insufficient resources for each service

D. The app will automatically scale without developer input

Solution

1. Step 1: Calculate developer needs

   5 services x 2 developers each = 10 developers needed.

2. Step 2: Compare with available team size

   Only 6 developers are available, which is less than 10, causing resource strain.

3. Final Answer:

   The team will struggle due to insufficient resources for each service -> Option C

4. Quick Check:

   Dev shortage = struggle managing microservices [OK]

Hint: Check if team size matches microservices needs [OK]

Common Mistakes:

• Assuming microservices scale developer needs automatically
• Ignoring team size constraints
• Thinking services merge automatically without effort

4. A team tries to convert a small monolithic app into microservices but faces deployment failures and communication errors. What is the most likely cause?

medium

A. Microservices do not support deployment automation

B. The app was too large for microservices

C. They used too many developers

D. They underestimated the complexity of managing microservices

Solution

1. Step 1: Analyze the problem context

   Small apps converted to microservices often face complexity in communication and deployment.

2. Step 2: Identify the cause

   Deployment failures and communication errors usually come from underestimating microservices management overhead.

3. Final Answer:

   They underestimated the complexity of managing microservices -> Option D

4. Quick Check:

   Underestimating complexity = deployment issues [OK]

Hint: Expect extra management work with microservices [OK]

Common Mistakes:

• Blaming microservices for deployment automation lack
• Assuming more developers cause deployment errors
• Thinking large apps cause these specific errors

5. A startup with a small team plans to build a new app. They want to decide between microservices and a monolithic design. Which approach should they choose and why?

hard

A. Start with a monolith to reduce complexity and switch later if needed

B. Start with microservices to prepare for future scaling immediately

C. Use microservices only if the app is a static website

D. Avoid both and build multiple separate apps

Solution

1. Step 1: Consider team size and app complexity

   A small team benefits from simpler monolithic design to reduce overhead and speed development.

2. Step 2: Plan for future growth

   Starting monolithic allows easier initial development; microservices can be adopted later if scaling is needed.

3. Final Answer:

   Start with a monolith to reduce complexity and switch later if needed -> Option A

4. Quick Check:

   Small team = start monolith [OK]

Hint: Small teams start monolith, scale to microservices later [OK]

Common Mistakes:

• Choosing microservices too early for small teams
• Confusing static websites with microservices use
• Ignoring future scalability planning