A team shows you a design with eight services. Without knowing the domain, what questions tell you whether the boundaries are right?

What the interviewer is testing

Whether you can evaluate a structure from its properties rather than needing to be a domain expert in every system you review.

The questions, and what each answer means

1. "Which of these get deployed together?" Any two that must ship as a pair are one service with a network call inside it. They have all the costs of distribution — failure, latency, no transaction — and none of the benefit. The boundary between them is wrong.

2. "Show me a common user journey and count the synchronous hops." A single action requiring a synchronous chain of five services has been cut across a workflow that belongs inside one boundary. It also means the journey's availability is the product of five availabilities.

3. "Who owns each database, and does anything else read it directly?" Two services on one schema is not two services. Direct reads of another service's tables are the single most common boundary violation and the hardest to undo, because every reader becomes coupled to an internal schema that was never designed as a contract.

4. "Which services do these three teams own?" Conway's Law is not optional. If one team owns six services they will drift into being one; if two teams share one service it will fracture. A boundary that cuts across ownership will be fought by gravity forever.

5. "What changes together? Show me your last ten pull requests." This is the strongest single question, because it is evidence rather than opinion. If most changes touch three services, those three have low cohesion between them and belong together.

6. "What happens to service A when service B is down?" If the answer is "it returns 500", A has inherited B's availability, and the boundary is not providing isolation — only distribution.

The heuristic underneath all six

Boundaries should follow change patterns, not technical layers or org convenience. Things that change together belong together; things that change independently can be separated. Every other test above is a proxy for this one.

What a strong answer adds

Noting that eight services for one team is very likely too many regardless of where the lines are, and that a modular monolith with the same eight modules would deliver the same separation of concerns with none of the distributed-systems cost — extractable later, once the change patterns have actually been observed rather than predicted.