Service decomposition strategies in Microservices - System Design Exercise

Design: Service Decomposition Strategies for Microservices

Focus on strategies for breaking down a monolith into microservices, including service boundaries, communication patterns, and data management. Out of scope: detailed implementation of each microservice.

Functional Requirements

FR1: Decompose a monolithic application into microservices

FR2: Ensure each service has a single responsibility

FR3: Enable independent deployment and scaling of services

FR4: Maintain data consistency and integrity across services

FR5: Support clear communication between services

Non-Functional Requirements

NFR1: Handle 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

NFR5: Data storage should be decentralized per service

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway

Service Registry and Discovery

Message Broker for asynchronous communication

Database per service

Load Balancer

Design Patterns

Domain-Driven Design (DDD) for defining service boundaries

Database per service pattern

API Gateway pattern

Event-driven architecture

Saga pattern for distributed transactions

Reference Architecture

                +-------------------+
                |    API Gateway    |
                +---------+---------+
                          |
        +-----------------+-----------------+
        |                 |                 |
+-------v-------+ +-------v-------+ +-------v-------+
|  User Service | | Order Service | | Payment Service|
+-------+-------+ +-------+-------+ +-------+-------+
        |                 |                 |
+-------v-------+ +-------v-------+ +-------v-------+
| User DB       | | Order DB      | | Payment DB    |
+---------------+ +---------------+ +---------------+

Services communicate asynchronously via message broker for events.

Components

API Gateway

Nginx or Kong

Entry point for clients, routes requests to appropriate services, handles authentication and rate limiting

User Service

Spring Boot / Node.js

Manages user profiles and authentication

Order Service

Spring Boot / Node.js

Handles order creation, updates, and queries

Payment Service

Spring Boot / Node.js

Processes payments and manages payment status

Message Broker

Apache Kafka / RabbitMQ

Enables asynchronous communication and event-driven workflows between services

Databases

PostgreSQL / MongoDB

Each service owns its database to ensure loose coupling and data encapsulation

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 an action affects other services, microservice publishes an event to the message broker.

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

6. Microservice returns response to API Gateway.

7. API Gateway sends response back to client.

Database Schema

Entities per service: - User Service: User(id, name, email, password_hash) - Order Service: Order(id, user_id, product_id, quantity, status) - Payment Service: Payment(id, order_id, amount, status) Relationships: - User Service owns User entity - Order Service references User by user_id (foreign key) - Payment Service references Order by order_id Each service manages its own database schema independently.

Scaling Discussion

Bottlenecks

API Gateway can become a single point of failure and bottleneck under high load

Database per service may face scaling challenges with large data volumes

Synchronous communication between services can increase latency and reduce availability

Eventual consistency can cause temporary data mismatches

Service discovery and load balancing complexity increases with number of services

Solutions

Deploy multiple API Gateway instances behind a load balancer for high availability

Use database sharding and read replicas to scale databases

Favor asynchronous communication with message brokers to decouple services

Implement compensating transactions and monitoring to handle eventual consistency

Use service registry tools like Consul or Eureka for dynamic service discovery

Interview Tips

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

Explain how you identify service boundaries using business domains

Discuss pros and cons of database per service pattern

Describe communication patterns: synchronous vs asynchronous

Highlight importance of loose coupling and independent deployability

Address data consistency challenges and solutions

Mention scalability and fault tolerance considerations

Practice

1. Which of the following best describes the main goal of service decomposition in microservices?

easy

A. Combining multiple services into one large service

B. Creating a single database for all services

C. Removing all dependencies between services

D. Breaking a large system into smaller, manageable services

Solution

1. Step 1: Understand the purpose of decomposition

   Service decomposition aims to split a big system into smaller parts for easier management.

2. Step 2: Evaluate options against this goal

   Only Breaking a large system into smaller, manageable services describes breaking down a system into smaller services, which matches the goal.

3. Final Answer:

   Breaking a large system into smaller, manageable services -> Option D

4. Quick Check:

   Service decomposition = smaller services [OK]

Hint: Decomposition means splitting big into small [OK]

Common Mistakes:

• Thinking decomposition means merging services
• Assuming it removes all dependencies
• Confusing decomposition with database design

2. Which of the following is a common strategy to decompose microservices?

easy

A. By server hardware

B. By business capability

C. By programming language

D. By network protocol

Solution

1. Step 1: Recall common decomposition strategies

   Common strategies include decomposing by business capability, subdomain, or data entity.

2. Step 2: Match options to known strategies

   Only By business capability matches a recognized strategy; others are unrelated to service design.

3. Final Answer:

   By business capability -> Option B

4. Quick Check:

   Decompose by business function = C [OK]

Hint: Decompose by what the business does [OK]

Common Mistakes:

• Choosing technical infrastructure as decomposition criteria
• Confusing programming language with service boundaries
• Thinking network protocols define services

3. Given a system with services decomposed by subdomain, which of the following is a likely benefit?

medium

A. Single point of failure for all features

B. Reduced number of services to manage

C. Improved team autonomy and focused development

D. Elimination of all data duplication

Solution

1. Step 1: Understand subdomain decomposition

   Decomposing by subdomain groups services by business areas, enabling teams to work independently.

2. Step 2: Analyze benefits

   This approach improves team autonomy and focus, but does not reduce services or eliminate data duplication fully.

3. Final Answer:

   Improved team autonomy and focused development -> Option C

4. Quick Check:

   Subdomain decomposition = team autonomy [OK]

Hint: Subdomain splits by business area, helps teams [OK]

Common Mistakes:

• Assuming fewer services means better decomposition
• Expecting zero data duplication always
• Thinking it creates single failure points

4. A team decomposed services by data entity but faces tight coupling between services. What is the likely cause?

medium

A. Services share too much data and depend on each other

B. Services are deployed on different servers

C. Services use different programming languages

D. Services have separate databases

Solution

1. Step 1: Identify cause of tight coupling

   Tight coupling often happens when services share data heavily and depend on each other.

2. Step 2: Evaluate options

   Only Services share too much data and depend on each other explains tight coupling due to shared data and dependencies; others are unrelated.

3. Final Answer:

   Services share too much data and depend on each other -> Option A

4. Quick Check:

   Tight coupling = shared data dependency [OK]

Hint: Tight coupling means services depend on shared data [OK]

Common Mistakes:

• Blaming deployment location for coupling
• Thinking different languages cause tight coupling
• Assuming separate databases cause coupling

5. You are designing a microservices system for an online store. Which decomposition strategy best supports independent team ownership and scalability?

hard

A. Decompose by business capability like order management, payment, and inventory

B. Decompose by database tables to minimize data duplication

C. Decompose by programming language to use best tools per service

D. Decompose by server location to reduce network latency

Solution

1. Step 1: Identify goals for decomposition

   Independent team ownership and scalability require clear service boundaries aligned with business functions.

2. Step 2: Match strategies to goals

   Decomposing by business capability groups related functions, enabling teams to own services and scale independently.

3. Step 3: Evaluate other options

   Decomposing by tables or languages does not align with team ownership; server location affects latency, not ownership.

4. Final Answer:

   Decompose by business capability like order management, payment, and inventory -> Option A

5. Quick Check:

   Business capability decomposition = team ownership + scalability [OK]

Hint: Group by business functions for team and scale benefits [OK]

Common Mistakes:

• Choosing database tables over business functions
• Thinking programming language defines service boundaries
• Focusing on server location instead of service design