How do you define service boundaries?

Direct answer

What a strong answer covers

How it works

A good boundary encloses a capability that changes together and can fail together: its data, the rules that keep that data consistent, and the API through which others use it. Signs of a correct split are that most requests are served inside one service, that a schema change rarely forces a coordinated deploy, and that an outage degrades one capability rather than everything. Boundaries drawn along database tables or org charts tend to produce chatty services that need distributed transactions to do simple work.

Example

Orders can own order state while payments own payment authorisation; coordinate through explicit contracts rather than direct table access. When the checkout flow needed the payment status on every order read, the fix was an event that copies a small status field into orders, not a join across two databases.

Common mistakes

• Splitting a monolith by technical layer so every feature crosses three services.
• Sharing a database between services and calling them independent.
• Creating a service per team even when two teams change the same invariant.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.