Bird
Raised Fist0
Microservicessystem_design~10 mins

Service decomposition strategies in Microservices - Interactive Code Practice

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to define a microservice based on business capability.

Microservices
class [1]Service:
    def __init__(self):
        pass

    def execute(self):
        print("Executing business logic")
Drag options to blanks, or click blank then click option'
ADatabase
BCache
COrder
DLogger
Attempts:
3 left
💡 Hint
Common Mistakes
Naming the service after technical components like 'Database' instead of business capabilities.
2fill in blank
medium

Complete the code to implement a microservice that communicates asynchronously using {{BLANK_1}}.

Microservices
def send_event(event):
    [1].publish(event)

send_event({'type': 'OrderCreated'})
Drag options to blanks, or click blank then click option'
AHTTP
BMessageQueue
CFTP
DSMTP
Attempts:
3 left
💡 Hint
Common Mistakes
Using HTTP which is synchronous instead of a message queue for async communication.
3fill in blank
hard

Fix the error in the code to correctly implement database per service pattern with {{BLANK_1}} isolation.

Microservices
class PaymentService:
    def __init__(self):
        self.db = [1]('payment_db')

    def save_payment(self, payment):
        self.db.insert(payment)
Drag options to blanks, or click blank then click option'
AFileStorage
BInMemoryCache
CSharedDatabase
DDedicatedDatabase
Attempts:
3 left
💡 Hint
Common Mistakes
Using a shared database which breaks service isolation.
4fill in blank
hard

Fill both blanks to implement API Gateway pattern with {{BLANK_1}} routing and {{BLANK_2}} aggregation.

Microservices
class APIGateway:
    def route_request(self, path):
        if path == '/orders':
            return self.[1]('OrderService')

    def aggregate_responses(self, responses):
        return [2](responses)
Drag options to blanks, or click blank then click option'
Aforward_request
Bcombine
Csend_email
Dlog_error
Attempts:
3 left
💡 Hint
Common Mistakes
Using unrelated methods like sending email or logging errors for routing or aggregation.
5fill in blank
hard

Fill all three blanks to implement event-driven communication with {{BLANK_1}} publishing, {{BLANK_2}} subscribing, and {{BLANK_3}} processing.

Microservices
class InventoryService:
    def publish_event(self, event):
        [1].send(event)

    def subscribe_events(self):
        [2].listen(self.process_event)

    def process_event(self, event):
        [3].process(event)
Drag options to blanks, or click blank then click option'
AEventBus
BEventListener
CCallback
DLogger
Attempts:
3 left
💡 Hint
Common Mistakes
Using Logger instead of event components for communication.

Practice

(1/5)
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