During a monolith decomposition, the new search service needs data owned by five other services. What do you do?

What the interviewer is testing

Whether you can maintain data ownership boundaries under pressure from a legitimate cross-cutting requirement — the hardest part of any decomposition.

The options and their costs

Query the five services synchronously per search. Search latency becomes the sum of five calls plus its own work, availability becomes the product of six services, and search — the highest-volume path — now loads every other service. Unworkable.

Read their databases directly. Fast, and it destroys the decomposition. Those services can no longer change their schemas, which means they are not independently deployable, which was the entire point.

Maintain a search-owned read model, populated from events. Each owning service publishes domain events; the search service consumes them and maintains its own index in the shape it needs.

The third is correct, and it is CQRS: search is a read model derived from the write models of several services.

What that requires

Published domain events with a contract, not raw database change records. Events should express business facts — a listing was published, a price changed — with a schema, a compatibility policy and an owner. Raw CDC couples search to five internal schemas and reproduces the direct-read problem.

A rebuild path. The index will need rebuilding after a defect or a mapping change, which means replaying from retained history. If that takes eleven hours during which search is degraded, the design is incomplete.

Reconciliation. The index will diverge — a missed event, an out-of-order apply, a bug. Silent divergence in search is particularly damaging because results look plausible. A periodic comparison against the sources is what detects it.

An explicit staleness budget, agreed with the product: how long after a listing changes must search reflect it?

What a strong answer adds

Recognising the general shape: any service needing a joined view across several owners is a read model, and the alternative — reaching into other services' data — is what turns a service architecture into a distributed monolith.

And that this is precisely why decomposition is a data problem rather than a code problem. Extracting logic is mechanical; deciding who owns each table and replacing the joins is the work.

Common weak answers

A shared database for "reference data". Synchronous calls with caching, which addresses latency and not the availability coupling.