Microservices Interview Questions: Boundaries, Data and Failure

Asked why microservices, most candidates say independent deployment, scaling, and team autonomy. It is correct, it is what every article says, and it earns nothing.

The follow-up is what it cost you, and that is where the round turns. Network calls that used to be function calls, transactions that no longer span the operation, debugging that now requires correlating three logs, and an operational burden that scales with service count.

Candidates who can name the cost are read as having operated microservices. Candidates who only have the benefits are read as having read about them.

Boundaries drawn around technical layers produce services that must be deployed together, which is the worst of both architectures. Boundaries drawn around business capabilities produce services that can change independently.

The practical test is the change test: when a typical feature arrives, how many services must change? If the answer is usually more than one, the boundary is wrong, and saying this demonstrates you have watched a split age.

Have an example of a split you would not do. A service owned by nobody, or one extracted so early that its interface was rewritten three times, are both credible and both show judgment.

Expect questions about a shared database. The strong answer is that it defeats the point: two services writing the same table cannot be deployed independently because a schema change belongs to both.

Expect distributed transactions. Know why two-phase commit is rarely used in practice, and be able to walk a saga: the steps, the compensating actions, and what happens if a compensation itself fails. That last part is what most candidates have not thought about.

Expect a question about querying across services. Have a position: API composition for small cases, a read model built from events for larger ones, and be able to say what staleness each accepts.

A dependency is slow rather than down: this is the question that separates experience from reading. Slow is worse than down, because down fails fast while slow exhausts your threads.

Cover timeouts, retries with backoff and jitter, and a circuit breaker. Then cover why retries can make an outage worse by multiplying load on a struggling dependency, which is the follow-up.

Be able to describe what you actually did to debug across services: correlation identifiers, tracing, and what was still hard. The candidate who says distributed debugging was genuinely difficult is more credible than the one who implies tracing solved it.