Single responsibility per service in Microservices - System Design Guide

Problem Statement

When a microservice handles multiple unrelated responsibilities, it becomes hard to maintain and scale. Changes in one function can unintentionally affect others, causing bugs and deployment delays. This tight coupling also slows down teams and increases the risk of system-wide failures.

Solution

Each microservice is designed to focus on one specific business capability or responsibility. This separation allows teams to develop, deploy, and scale services independently. It reduces complexity, improves fault isolation, and makes the system easier to understand and evolve.

Architecture

┌───────────────┐     ┌───────────────┐     ┌───────────────┐
│ User Service  │ →→→ │ Order Service │ →→→ │ Payment Service│
└───────────────┘     └───────────────┘     └───────────────┘

Each box is a microservice with a single responsibility. Arrows show communication flow.

This diagram shows three microservices, each handling a distinct responsibility: user management, order processing, and payment handling. They communicate through defined interfaces.

Trade-offs

✓ Pros

→

Improves maintainability by isolating changes to one service.

→

Enables independent deployment and scaling of services.

→

Enhances fault tolerance by limiting failure impact to one service.

→

Simplifies understanding of each service's purpose.

✗ Cons

→

Increases the number of services to manage, adding operational overhead.

→

Requires well-defined APIs and communication patterns between services.

→

Can introduce latency due to inter-service calls.

When the system has multiple distinct business capabilities and teams can own separate services. Typically beneficial at scale beyond 10,000 daily active users or when deployment agility is critical.

For very small or simple applications with limited functionality where the overhead of multiple services outweighs benefits, such as prototypes or MVPs with fewer than 1,000 users.

Real World Examples

Amazon

Amazon decomposed its monolithic e-commerce platform into microservices each responsible for a single domain like product catalog, order management, and payment processing to enable independent scaling and faster deployments.

Netflix

Netflix uses single responsibility microservices to isolate streaming, user profiles, and recommendations, allowing teams to innovate and deploy features independently without affecting the entire system.

Uber

Uber splits services by responsibility such as ride matching, payments, and notifications, enabling rapid development and fault isolation in their complex, high-scale platform.

Code Example

The before code shows one class handling user creation, order placement, and payment processing, mixing responsibilities. The after code splits these into three classes, each focused on a single responsibility, making the code easier to maintain and scale.

Microservices

### Before: Single service handling multiple responsibilities
class ECommerceService:
    def create_user(self, user_data):
        # code to create user
        pass

    def place_order(self, order_data):
        # code to place order
        pass

    def process_payment(self, payment_data):
        # code to process payment
        pass


### After: Separate services each with single responsibility

# User Service
class UserService:
    def create_user(self, user_data):
        # code to create user
        pass

# Order Service
class OrderService:
    def place_order(self, order_data):
        # code to place order
        pass

# Payment Service
class PaymentService:
    def process_payment(self, payment_data):
        # code to process payment
        pass

Alternatives

Monolithic architecture

All responsibilities are combined into a single deployable unit without service boundaries.

Use when: When the application is small, simple, or early in development and team size is small.

Modular monolith

Keeps a single deployable unit but enforces clear module boundaries internally without separate services.

Use when: When you want clear separation of concerns but want to avoid distributed system complexity.

Summary

Single responsibility per service means each microservice handles one business capability.

This separation improves maintainability, scalability, and fault isolation.

It is best used in systems with multiple distinct domains and larger teams.

Practice

1. What does the single responsibility principle mean in microservices?

easy

A. Services should be tightly coupled to improve performance.

B. Each service should handle multiple unrelated tasks.

C. Services should share the same database for all tasks.

D. Each service should do only one specific job.

Solution

1. Step 1: Understand the principle meaning

   Single responsibility means one service focuses on one task or job only.

2. Step 2: Evaluate options against this meaning

   Each service should do only one specific job. matches the principle exactly; others contradict it by mixing tasks or coupling.

3. Final Answer:

   Each service should do only one specific job. -> Option D

4. Quick Check:

   Single responsibility = One job per service [OK]

Hint: One service, one job keeps design simple and clear [OK]

Common Mistakes:

• Thinking one service can do many unrelated tasks
• Assuming shared databases mean single responsibility
• Confusing tight coupling with single responsibility

2. Which of the following is the correct way to name a microservice following single responsibility?

easy

A. UserManagementService

B. UserAndOrderService

C. Service123

D. DatabaseService

Solution

1. Step 1: Identify naming that reflects single responsibility

   The service name should clearly indicate one focused responsibility.

2. Step 2: Check options for clarity and focus

   UserManagementService clearly states it manages users only; others mix concerns or are vague.

3. Final Answer:

   UserManagementService -> Option A

4. Quick Check:

   Clear, focused name = single responsibility [OK]

Hint: Service name should reflect one clear job [OK]

Common Mistakes:

• Using vague or numeric names without meaning
• Combining multiple domains in one service name
• Naming services after infrastructure components

3. Given these microservices: UserService handles user data, OrderService handles orders. Which service should handle payment processing?

medium

A. UserService

B. PaymentService

C. OrderService

D. DatabaseService

Solution

1. Step 1: Analyze responsibilities of existing services

   UserService manages users, OrderService manages orders, so payment is a separate concern.

2. Step 2: Assign payment to a dedicated service

   Payment processing is a distinct responsibility, so PaymentService is appropriate.

3. Final Answer:

   PaymentService -> Option B

4. Quick Check:

   Separate payment = separate service [OK]

Hint: Separate distinct jobs into separate services [OK]

Common Mistakes:

• Assigning payment to unrelated services
• Combining payment with user or order logic
• Using generic service names that mix concerns

4. You find a microservice called InventoryAndShippingService causing deployment issues. What is the best fix following single responsibility?

medium

A. Merge it with UserService to reduce services

B. Add more features to InventoryAndShippingService

C. Split it into two services: InventoryService and ShippingService

D. Keep it as is and increase server resources

Solution

1. Step 1: Identify problem with combined responsibilities

   Inventory and shipping are two distinct jobs combined, causing complexity and deployment issues.

2. Step 2: Apply single responsibility by splitting services

   Splitting into InventoryService and ShippingService isolates concerns and simplifies management.

3. Final Answer:

   Split it into two services: InventoryService and ShippingService -> Option C

4. Quick Check:

   Split combined services to fix issues [OK]

Hint: Split combined services to fix complexity [OK]

Common Mistakes:

• Merging unrelated services increases complexity
• Adding features to overloaded services worsens problems
• Ignoring root cause and just adding resources

5. You are designing a microservices system for an online store. Which design best follows single responsibility per service?

hard

A. UserService, ProductService, OrderService, PaymentService, NotificationService

B. StoreService handling users, products, orders, payments, and notifications

C. UserService and OrderService only, handling all tasks

D. One big service for all store functions

Solution

1. Step 1: Understand the scope of each option

   UserService, ProductService, OrderService, PaymentService, NotificationService splits store functions into focused services; others combine many tasks.

2. Step 2: Match design to single responsibility principle

   UserService, ProductService, OrderService, PaymentService, NotificationService clearly assigns one responsibility per service, making it scalable and maintainable.

3. Final Answer:

   UserService, ProductService, OrderService, PaymentService, NotificationService -> Option A

4. Quick Check:

   One service, one job = UserService, ProductService, OrderService, PaymentService, NotificationService [OK]

Hint: Split big tasks into small focused services [OK]

Common Mistakes:

• Combining many tasks into one service
• Using too few services for complex domains
• Ignoring scalability and maintainability