Single responsibility per service in Microservices - System Design Exercise

Design: Microservices with Single Responsibility

Design focuses on defining microservices boundaries, communication, and data ownership. Infrastructure details like cloud provider or CI/CD pipelines are out of scope.

Functional Requirements

FR1: Each microservice should have one clear responsibility or business capability.

FR2: Services must communicate with each other to fulfill user requests.

FR3: The system should allow independent deployment and scaling of each service.

FR4: Services should handle failures gracefully without affecting others.

FR5: Data owned by each service should be encapsulated and not shared directly.

Non-Functional Requirements

NFR1: Support up to 10,000 concurrent users.

NFR2: API response latency p99 under 300ms.

NFR3: Availability target of 99.9% uptime.

NFR4: Services must be loosely coupled and independently deployable.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway or Service Mesh for routing

Individual microservices each with own database

Message broker for asynchronous communication

Load balancers

Monitoring and logging tools

Design Patterns

Domain-Driven Design (DDD) for service boundaries

Event-driven architecture

Circuit breaker pattern for fault tolerance

Database per service pattern

API Gateway pattern

Reference Architecture

          +-------------------+          
          |    API Gateway    |          
          +---------+---------+          
                    |                    
    +---------------+---------------+    
    |               |               |    
+---v---+       +---v---+       +---v---+
|User   |       |Order  |       |Payment|
|Service|       |Service|       |Service|
+---+---+       +---+---+       +---+---+
    |               |               |    
+---v---+       +---v---+       +---v---+
|UserDB |       |OrderDB|       |PayDB  |
+-------+       +-------+       +-------+

Services communicate via API Gateway for sync calls and use message broker for async events.

Components

API Gateway

Nginx or Kong

Routes client requests to appropriate microservices and handles authentication.

User Service

Node.js/Express or Spring Boot

Manages user profiles and authentication.

Order Service

Node.js/Express or Spring Boot

Handles order creation, updates, and queries.

Payment Service

Node.js/Express or Spring Boot

Processes payments and manages payment status.

Databases

PostgreSQL or MongoDB

Each service owns its own database to encapsulate data.

Message Broker

RabbitMQ or Kafka

Enables asynchronous communication between services.

Request Flow

1. Client sends request to API Gateway.

2. API Gateway routes request to the appropriate microservice based on URL and method.

3. Microservice processes request using its own database.

4. If needed, microservice publishes events to message broker for other services.

5. Other services subscribe to relevant events and update their state asynchronously.

6. Microservice returns response to API Gateway.

7. API Gateway sends response back to client.

Database Schema

User Service: User(id PK, name, email, password_hash) Order Service: Order(id PK, user_id FK, product_id, quantity, status) Payment Service: Payment(id PK, order_id FK, amount, status, payment_method) Each service owns its schema and does not share tables directly.

Scaling Discussion

Bottlenecks

API Gateway can become a single point of failure or bottleneck.

Database performance under high load for each service.

Message broker throughput limits.

Inter-service communication latency.

Deployment complexity as number of services grows.

Solutions

Use multiple API Gateway instances behind a load balancer.

Scale databases vertically or use read replicas; consider sharding if needed.

Deploy a clustered message broker with partitioning.

Use caching and optimize communication patterns (batching, async).

Automate deployment with container orchestration (Kubernetes) and use service discovery.

Interview Tips

Time: Spend 10 minutes clarifying requirements and scope, 20 minutes designing service boundaries and communication, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain importance of single responsibility to reduce complexity and improve maintainability.

Discuss how data ownership per service avoids tight coupling.

Describe communication methods and their trade-offs (sync vs async).

Highlight fault tolerance with circuit breakers and retries.

Mention scaling strategies and deployment independence.

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