[Solved] A team notices that their UserService and NotificationService are tightly coupled because UserService calls NotificationService directly for every... What is the best way to fix this boundary issue? | Microservices

Microservices - Migration from Monolith

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?

AMake NotificationService call UserService instead

BMerge both services into one to avoid communication

CUse an event-driven approach where UserService emits events and NotificationService listens

DRemove NotificationService and handle notifications inside UserService

Step-by-Step Solution

Solution:

Step 1: Understand tight coupling problem
Direct calls create dependencies that reduce service independence.
Step 2: Apply event-driven design
Emitting events decouples services, allowing independent scaling and deployment.
Final Answer:
Use an event-driven approach where UserService emits events and NotificationService listens -> Option C
Quick Check:
Event-driven decoupling = C [OK]

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

Common Mistakes:

Merging services unnecessarily
Reversing call direction without decoupling
Ignoring decoupling benefits

Master "Migration from Monolith" in Microservices

9 interactive learning modes - each teaches the same concept differently

Learn Why Deep Arch Try Challenge Design Recall Scale

More Microservices Quizzes

What is the best way to fix this boundary issue?

Step 1: Understand tight coupling problem

Step 2: Apply event-driven design

Final Answer:

Quick Check:

Want More Practice?