A service boundary should group behavior that changes together and owns a coherent business responsibility. Splitting by technical layers often creates constant cross-service coordination.
Before you start
You should understand HTTP, database transactions and the difference between one process and independently failing services. Draw the participants and message direction before choosing a pattern. Include timeout, duplicate delivery and recovery in the model instead of considering only successful requests.
The practical goal is to reason through this situation: An order service owns order rules rather than merely exposing one table. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Trace business changes
List behavior and data that usually change together.
Step 2: Locate atomic invariants
Keep tightly coupled rules together unless separation offers a justified benefit.
Step 3: Evaluate independent operation
Count cross-service calls and coordination introduced by the proposed split.
Worked scenario
An order service owns order rules rather than merely exposing one table.
An order-table service and order-validation service require joint changes for an ordinary checkout rule. Splitting those technical pieces creates deployment coordination without independent business ownership. A fulfillment capability with distinct rules and lifecycle may be a stronger boundary, provided its interaction with orders has an explicit contract.
Common mistake
One service per table can produce distributed joins for ordinary operations.
Verify the behavior
Trace three common changes and one failure through both proposed designs.
Interview exercise
Evaluate a proposed split.
Answer and reasoning
Trace common changes and transactions; keep tightly coupled invariants together unless the independent boundary offers measurable value.
Continue learning
Compare the scenario with the Microservices interview questions and test your understanding with the Microservices MCQs. For terminology and implementation details, consult the reference material.