What is service decomposition and how do you decide service boundaries?
Learn service decomposition and how to draw microservice boundaries using business capabilities and DDD bounded contexts for cohesive, loosely coupled services.
Expected Interview Answer
Service decomposition is the process of breaking a system into microservices, and boundaries are best drawn around business capabilities or Domain-Driven Design bounded contexts so each service is highly cohesive internally and loosely coupled to the others.
The goal is that each service owns one clear responsibility and its own data, changes for a single business reason, and can be developed and deployed by one team. Practically you decompose by business capability or bounded context, keep things that change together inside the same service, and split things that change for different reasons or scale differently. Getting boundaries wrong leads to a distributed monolith — services that must be deployed together and chat constantly across the network — so you look for stable interfaces, minimal cross-service transactions, and low chatter as signs the boundaries are right.
- High cohesion within each service
- Loose coupling between services
- Clear single-team ownership per service
- Fewer distributed transactions and cross-service calls
- Boundaries aligned with how the business actually changes
AI Mentor Explanation
Deciding service boundaries is like organizing a squad by discipline: batting, bowling, and fielding drills each become a self-contained unit with its own coach and plan. You group skills that are practiced together and separate ones that are not, so each unit improves independently instead of tangling every session into one chaotic net.
Step-by-Step Explanation
Step 1
Map business capabilities
List what the business does — ordering, billing, shipping — as candidate service boundaries rather than technical layers.
Step 2
Identify bounded contexts
Use Domain-Driven Design to find contexts where a term has one consistent meaning, and draw a service around each.
Step 3
Group by rate and reason of change
Keep things that change together inside one service; split things that change for different business reasons.
Step 4
Minimize cross-service coupling
Prefer boundaries that need few synchronous calls and avoid distributed transactions across services.
Step 5
Validate with chatter and ownership
If two services talk constantly or need the same team to deploy together, redraw the boundary.
What Interviewer Expects
- Decomposition by business capability or bounded context, not technical layers
- Understanding of high cohesion and loose coupling
- Awareness of the distributed-monolith anti-pattern
- Mention of database-per-service and data ownership
- Using change reasons and team ownership to guide boundaries
Common Mistakes
- Decomposing by technical layer (UI, service, data) instead of capability
- Making services so fine-grained they chat constantly over the network
- Sharing a database across services and coupling them through it
- Ignoring bounded contexts and creating overlapping responsibilities
- Creating a distributed monolith that must be deployed together
Best Answer (HR Friendly)
“Service decomposition is deciding how to split a big system into smaller services, and the trick is to draw the lines around distinct business areas so each service does one job well and rarely depends on the others. Good boundaries mean each team can work on its own piece without constantly waiting on or breaking someone else's.”
Code Example
E-commerce domain
Catalog context -> Catalog service (products, pricing)
Ordering context -> Order service (carts, orders)
Payment context -> Payment service (charges, refunds)
Fulfillment context -> Shipping service (shipments, tracking)
Rule of thumb:
high cohesion inside a context, few calls between contexts,
each context owns its own data store.Follow-up Questions
- What is a bounded context in Domain-Driven Design?
- What is a distributed monolith and how do you avoid it?
- How do you handle a transaction that spans multiple services?
- How small should a microservice be?
- How do you decompose an existing monolith incrementally (strangler fig)?
MCQ Practice
1. What is the recommended basis for drawing microservice boundaries?
Boundaries around business capabilities or DDD bounded contexts yield cohesive, loosely coupled services.
2. Which symptom suggests boundaries were drawn incorrectly?
Services that must deploy together and talk constantly form a distributed monolith — a sign of bad boundaries.
3. What data pattern supports clean decomposition?
Each service owning its own data prevents coupling through a shared schema and keeps boundaries independent.
Flash Cards
What is service decomposition? — Breaking a system into microservices, drawing boundaries around business capabilities or bounded contexts.
Two goals of good boundaries? — High cohesion inside each service and loose coupling between services.
Distributed monolith? — Badly bounded services that must deploy together and call each other constantly — the anti-pattern to avoid.
How to test a boundary? — Low cross-service chatter, few distributed transactions, and single-team ownership signal a good boundary.
Continue Learning
Related Interview Questions
What are common microservices anti-patterns and best practices?
hard
A service needs data owned by another service on almost every request. Do you call it, cache it, or copy it into a read model?
hard
What is the difference between a monolithic and a microservices architecture?
medium
What is a bounded context in domain-driven design and how does it map to microservices?
medium