Identifying service boundaries in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a microservice responsible for user authentication.

Microservices

class AuthService:
    def __init__(self):
        self.[1] = []  # Store user credentials

Drag options to blanks, or click blank then click option'

Ausers

Borders

Cpayments

Dinventory

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing unrelated data like orders or payments for authentication service.

The AuthService should manage user credentials, so the correct attribute is users.

2fill in blank

medium

Complete the code to separate order processing into its own microservice.

Microservices

class OrderService:
    def process_order(self, order):
        # Validate order
        if not order.[1]:
            raise ValueError('Invalid order')

Drag options to blanks, or click blank then click option'

Auser

Bid

Cstock

Dprice

Attempts:

3 left

💡 Hint

Common Mistakes

Using price or stock which are attributes but not unique identifiers.

Each order should have a unique id to identify it during processing.

3fill in blank

hard

Fix the error in the service boundary definition by choosing the correct domain for payment processing.

Microservices

class PaymentService:
    def __init__(self):
        self.[1] = []  # Store payment transactions

Drag options to blanks, or click blank then click option'

Apayments

Busers

Corders

Dinventory

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing payments with user or order data.

The PaymentService should manage payments, not users or orders.

4fill in blank

hard

Fill both blanks to correctly define service boundaries for inventory and order services.

Microservices

class InventoryService:
    def __init__(self):
        self.[1] = []  # Store inventory items

class OrderService:
    def __init__(self):
        self.[2] = []  # Store customer orders

Drag options to blanks, or click blank then click option'

Aitems

Borders

Cusers

Dpayments

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up orders with inventory items or users.

The InventoryService manages items, and the OrderService manages orders.

5fill in blank

hard

Fill all three blanks to correctly assign responsibilities in a microservices architecture.

Microservices

class UserService:
    def __init__(self):
        self.[1] = []  # Store user profiles

class OrderService:
    def __init__(self):
        self.[2] = []  # Store orders

class PaymentService:
    def __init__(self):
        self.[3] = []  # Store payment records

Drag options to blanks, or click blank then click option'

Aprofiles

Borders

Cpayments

Ditems

Attempts:

3 left

💡 Hint

Common Mistakes

Assigning wrong data to services, like payments to UserService.

UserService manages profiles, OrderService manages orders, and PaymentService manages payments.

Practice

1. Which of the following best describes the primary goal when identifying service boundaries in microservices?

easy

A. Create services based on the number of developers available

B. Split services evenly by code size

C. Group all database operations into one service

D. Divide the system based on business capabilities and data ownership

Solution

1. Step 1: Understand the purpose of service boundaries

   Service boundaries should reflect business capabilities to ensure clear ownership and independent deployment.

2. Step 2: Evaluate the options

   Options B, C, and D focus on technical or team size factors, which are less effective than business-driven boundaries.

3. Final Answer:

   Divide the system based on business capabilities and data ownership -> Option D

4. Quick Check:

   Business capabilities = A [OK]

Hint: Match services to business functions, not code size or teams [OK]

Common Mistakes:

• Splitting services by code size only
• Grouping all database logic in one service
• Ignoring business domain boundaries

2. Which of the following is the correct way to define a microservice boundary?

easy

A. A service that handles user authentication and profile management

B. A service that mixes payment processing and product catalog updates

C. A service that only manages database connections

D. A service that handles logging for all other services

Solution

1. Step 1: Identify cohesive responsibilities

   A good service boundary groups related business functions, like authentication and profile management.

2. Step 2: Check for unrelated responsibilities

   Options A, B, and C mix unrelated concerns or are cross-cutting, which should be separate services or infrastructure.

3. Final Answer:

   A service that handles user authentication and profile management -> Option A

4. Quick Check:

   Cohesive business functions = D [OK]

Hint: Group related business tasks in one service [OK]

Common Mistakes:

• Combining unrelated business functions
• Creating services for technical concerns only
• Mixing cross-cutting concerns inside business services

3. Given a system with services: OrderService managing orders, InventoryService managing stock, and PaymentService handling payments, which service boundary violation is shown if OrderService directly updates stock quantities?

medium

A. OrderService is violating the single responsibility principle by managing inventory data

B. OrderService is correctly handling all order-related data including stock

C. PaymentService should update stock quantities instead

D. InventoryService should not exist separately from OrderService

Solution

1. Step 1: Analyze service responsibilities

   OrderService should focus on orders; InventoryService owns stock data and updates.

2. Step 2: Identify boundary violation

   OrderService updating stock breaks clear ownership and single responsibility principles.

3. Final Answer:

   OrderService is violating the single responsibility principle by managing inventory data -> Option A

4. Quick Check:

   Single responsibility violation = B [OK]

Hint: Each service owns its data; no direct updates outside boundaries [OK]

Common Mistakes:

• Allowing services to update data owned by others
• Confusing payment service role
• Merging unrelated services unnecessarily

4. A team notices that their UserService and NotificationService are tightly coupled because UserService calls NotificationService directly for every user update. What is the best way to fix this boundary issue?

medium

A. Make NotificationService call UserService instead

B. Merge both services into one to avoid communication

C. Use an event-driven approach where UserService emits events and NotificationService listens

D. Remove NotificationService and handle notifications inside UserService

Solution

1. Step 1: Understand tight coupling problem

   Direct calls create dependencies that reduce service independence.

2. Step 2: Apply event-driven design

   Emitting events decouples services, allowing independent scaling and deployment.

3. Final Answer:

   Use an event-driven approach where UserService emits events and NotificationService listens -> Option C

4. Quick Check:

   Event-driven decoupling = C [OK]

Hint: Use events to decouple services, not direct calls [OK]

Common Mistakes:

• Merging services unnecessarily
• Reversing call direction without decoupling
• Ignoring decoupling benefits

5. You are designing a microservices system for an e-commerce platform. Which approach best defines service boundaries to maximize team autonomy and scalability?

hard

A. Create services based on technical layers like UI, Business Logic, and Database Access

B. Define services around distinct business domains like Catalog, Orders, Payments, and Shipping, each owning its data and APIs

C. Split services by database tables regardless of business function

D. Group all user-related features into one large service to reduce communication

Solution

1. Step 1: Identify business domain boundaries

   Services aligned with business domains allow clear ownership and independent scaling.

2. Step 2: Avoid technical or data-layer splits

   Splitting by technical layers or tables causes tight coupling and reduces autonomy.

3. Step 3: Consider team autonomy and scalability

   Domain-based services enable teams to work independently and scale services as needed.

4. Final Answer:

   Define services around distinct business domains like Catalog, Orders, Payments, and Shipping, each owning its data and APIs -> Option B

5. Quick Check:

   Domain-driven design = A [OK]

Hint: Align services with business domains for autonomy and scale [OK]

Common Mistakes:

• Splitting by technical layers instead of business domains
• Grouping unrelated features together
• Ignoring data ownership in service design