Service decomposition strategies in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identifying the primary principle of domain-driven design (DDD) in service decomposition

Which of the following best describes the main idea behind using domain-driven design (DDD) for decomposing microservices?

A Decompose services based on technical layers like UI, business logic, and database

B Create one service per database table to simplify data access

C Split services according to business capabilities and bounded contexts

D Group all functionalities into a single service to reduce communication overhead

💡 Hint

Think about how business domains guide service boundaries.

Domain-driven design focuses on dividing systems by business domains and bounded contexts, which helps create services aligned with real-world business capabilities.

❓ Architecture

intermediate

Choosing the best decomposition strategy for a retail platform

A retail platform wants to decompose its monolith into microservices. Which decomposition strategy would best isolate the payment processing functionality?

A Decompose by technical layers: UI service, payment service, and database service

B Decompose by business capabilities: separate payment service from order and inventory services

C Decompose by database tables: one service per table including payment table service

D Decompose by user roles: one service for customers, one for admins, one for payment

💡 Hint

Consider which approach isolates business functions clearly.

Decomposing by business capabilities isolates payment processing as its own service, which improves maintainability and scalability.

❓ scaling

advanced

Scaling challenges with database-per-service pattern

What is a common scaling challenge when using the database-per-service pattern in microservices?

A Data consistency becomes difficult due to distributed transactions across multiple databases

B All services must use the same database technology, limiting flexibility

C Services cannot scale independently because they share a single database

D Scaling is automatic and requires no additional design considerations

💡 Hint

Think about how data consistency is managed across services.

Using separate databases per service leads to challenges in maintaining data consistency because distributed transactions are complex and often avoided.

❓ tradeoff

advanced

Tradeoff of fine-grained vs coarse-grained service decomposition

What is a key tradeoff when choosing fine-grained service decomposition over coarse-grained in microservices?

A Fine-grained services increase the number of network calls and operational overhead

B Fine-grained services reduce network calls but increase code complexity

C Coarse-grained services always improve fault isolation compared to fine-grained

D Coarse-grained services eliminate the need for service discovery mechanisms

💡 Hint

Consider how service size affects communication and management.

Fine-grained services lead to more network calls and higher operational complexity, while coarse-grained services reduce calls but may be less flexible.

❓ estimation

expert

Estimating service count from bounded contexts

A system has 5 bounded contexts identified by domain experts. Each bounded context is expected to be decomposed into 3 microservices on average. What is the estimated total number of microservices after decomposition?

A 5

B 8

C 20

D 15

💡 Hint

Multiply the number of bounded contexts by the average services per context.

Multiplying 5 bounded contexts by 3 services each results in 15 total microservices.