How do you decide the service boundaries in your high-level design?

Question

Accepted Answer

The most common failure is splitting by technical layer rather than by domain.

Good boundaries:

Around a business capability - Order, Payment, Inventory, Notification. Each owns its data and can be described in one sentence.
Where data ownership is exclusive. If two services write to the same table, they are one service pretending to be two.
Where scaling profiles genuinely differ. Image processing is CPU-bound and bursty; the user API is I/O-bound and steady. Separating lets each scale independently.
Along team lines - Conway's Law is real; a service owned by two teams will have a contested roadmap.
Where failure should be isolated. Recommendations going down must not stop checkout.

Bad boundaries: splitting into "read service" and "write service" for the same entity; a service so small that every feature needs three of them to change together (a distributed monolith); and splitting before the domain is understood.

The test to state: "If a typical feature request requires changing three services and coordinating their deploys, the boundaries are wrong." A well-bounded service can ship a feature alone.

Safest position in an interview: start with a modular monolith with clear internal boundaries, then extract services where a boundary has proven itself under real load.

How do you decide the service boundaries in your high-level design?

Answer with Explanation