Identifying service boundaries in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identifying service boundaries based on business capabilities

Which of the following best describes how to identify service boundaries in a microservices architecture?

A Group services by technical layers such as database, API, and UI to separate concerns.

B Split services based on the size of the development team to balance workload.

C Create one large service that handles all business logic to reduce network calls.

D Define services around distinct business capabilities or domains to ensure loose coupling.

💡 Hint

Think about how to keep services independent and aligned with business goals.

Services should be designed around business capabilities to ensure they are loosely coupled and independently deployable. Grouping by technical layers or team size does not align with domain-driven design principles.

❓ Architecture

intermediate

Choosing service boundaries for an e-commerce platform

You are designing microservices for an e-commerce platform. Which service boundary division is most appropriate?

A Separate services for user authentication, product catalog, order processing, and payment handling.

B Separate services for frontend UI, backend API, and database access.

C Separate services by geographic region to optimize latency.

D Separate services by programming language used for development.

💡 Hint

Consider how to align services with distinct business functions.

Dividing services by business functions like authentication, catalog, orders, and payments aligns with service boundaries that support independent development and deployment. Dividing by UI/backend or geography is less effective for business logic separation.

❓ scaling

advanced

Scaling microservices by service boundaries

Which approach best supports scaling microservices independently based on service boundaries?

A Design services so that each handles multiple unrelated business functions to maximize resource use.

B Design services around single business capabilities so they can be scaled independently as demand varies.

C Combine all services into one monolith to simplify scaling decisions.

D Scale services only by increasing database capacity regardless of service boundaries.

💡 Hint

Think about how service boundaries affect independent scaling.

When services are designed around single business capabilities, they can be scaled independently based on their specific load. Combining unrelated functions or scaling only the database limits flexibility and efficiency.

❓ tradeoff

advanced

Tradeoffs in defining service boundaries

What is a common tradeoff when defining very fine-grained service boundaries in microservices?

A Improved performance due to fewer network calls between services.

B Simpler deployment because fewer services exist to manage.

C Increased complexity in communication and data consistency across many small services.

D Reduced fault tolerance because all logic is in one service.

💡 Hint

Consider what happens when services are too small and numerous.

Very fine-grained services increase the number of network calls and complexity in maintaining data consistency, which can make the system harder to manage despite modularity benefits.

❓ estimation

expert

Estimating number of microservices for a ride-sharing app

You are tasked with estimating the number of microservices needed for a ride-sharing app. The app includes user management, ride matching, payment processing, driver tracking, and notifications. Which is the most reasonable estimate?

A 5 or more services, each focused on a distinct business capability like user management, ride matching, payment, driver tracking, and notifications.

B 2 services: one for users and rides, one for payments and notifications.

C 10 services, splitting each feature into multiple smaller services regardless of business boundaries.

D 1 service handling all features to reduce complexity.

💡 Hint

Think about aligning services with clear business capabilities without over-fragmenting.

Estimating one service per major business capability balances modularity and manageability. Too few services combine unrelated logic; too many services increase complexity unnecessarily.