For a retailer, should order management, payment and fulfilment be one service or three?

What the interviewer is testing

Whether you separate logical modularity from physical distribution and can justify sequencing.

The reasoning

These are genuinely different domains with different rules, different rates of change and potentially different owners — so the logical separation is right.

The question is whether they need to be separately deployable, and that depends on facts not given: how many teams, whether they scale differently, whether they have different compliance requirements.

Why start with one deployable

Boundaries are hard to get right initially. Moving a boundary inside a codebase is a refactor; moving one between services is a data migration with contract changes and coordinated deployment. Starting with enforced modules keeps the boundary cheap to correct while understanding improves.

Transactions. Order creation and payment authorisation want to be atomic. Split across services, that becomes a saga with compensation, eventual consistency and an operator interface for stuck instances. That complexity is worth paying when there is a reason; it is not worth paying by default.

Operational cost. Three services means three deployment pipelines, three on-call surfaces, three sets of telemetry.

The enforcement that makes it work

Automated boundary checks — an architecture test failing the build when one module reaches into another's internals or its tables. A boundary maintained by convention erodes within months under delivery pressure; one that fails the build does not.

This is what Shopify's Packwerk does for their Rails monolith, and it is what makes "modular monolith" a real architecture rather than an intention.

When to extract

When a specific module has a named constraint: fulfilment needs to scale independently for peak, payment has a compliance boundary that warrants isolation, or a separate team takes ownership. Extract that one. A well-enforced module is straightforward to extract.

What a strong answer adds

The evidence to gather before splitting: how many services must change for a typical feature. If splitting these three would mean every order-related change touches all three, they are not independent and the split would produce a distributed monolith.

Common weak answers

Three services because they are three domains, conflating logical and physical separation. One service with no internal boundaries.