What they're testing
Whether you know the operational price of distribution, or just find it more modern.
The short answer~30 seconds
I choose a modular monolith with clear internal boundaries. Microservices solve the problem of several teams needing to deploy independently — an organisational problem, not a code one. Before you have it, you inherit: every function call becomes a network call that can fail, transactions become sagas, debugging needs distributed tracing, and a local environment means running eight services. In exchange for essentially nothing.
The long answer
The usual argument for microservices is independent scaling. It's true in principle and rarely the binding constraint: running more instances of the whole monolith is almost always cheaper than the engineering cost of splitting, until one component has a genuinely DIFFERENT resource profile — CPU-bound video processing next to an API that mostly waits on I/O. That's a valid technical reason to extract, and it extracts one thing rather than everything.
Crucially, a monolith doesn't mean tangled code. A modular monolith keeps boundaries explicit inside one process: each module has its own public API, may not touch another module's tables, and can own a schema within the same database. Do that and extracting a service later is a planned refactor rather than a rewrite — you've already paid the hard part, which is finding the boundary.
On the cost of distribution, the number to remember: a function call is nanoseconds, an in-region network call is around half a millisecond. Six orders of magnitude. An endpoint traversing five services spends milliseconds on network alone, and each hop is somewhere a timeout can happen. Which is why a poorly-factored microservice architecture is frequently SLOWER than the monolith it replaced.
What they'll ask next
?So when do you split?
When deploy coordination becomes the bottleneck — several teams waiting on each other to release; when one component has a genuinely different resource or availability profile; or when a part must be isolated for compliance. All three are observable, unlike "I hear it's better".
?How do you split safely?
Strangler fig: stand the new service alongside, route paths through it one at a time, and keep the old path until its traffic reaches zero. There's never a big-bang cutover, so you can always retreat.
These lose points
- Splitting by technical layer (a database service, a business-logic service). That's a distributed monolith — worse than either option.
- Not mentioning operational cost: multiplied CI/CD, tracing, service discovery, local environments.