Microservices Interview Questions
Microservices interviews are mostly about three things: where the boundaries go, what happens to consistency once a transaction cannot span them, and what each service does when its dependencies misbehave. Everything else — service discovery, gateways, meshes — is mechanism in service of those questions.
The strongest candidates are notably unenthusiastic about microservices. They can state what the architecture costs: a network hop that can fail, consistency that is no longer free, a debugging path that spans services, and an operational burden multiplied by service count. Interviewers increasingly treat that sobriety as the signal, because the failure mode in the field is splitting too early and too finely.
Written and reviewed by Sahil Srivastav
What the bar actually is
You should be able to justify a boundary from something durable — a business capability with its own data and its own rate of change — rather than from a layer or a team structure. Boundaries drawn around technical layers produce services that cannot change independently, which forfeits the only real benefit while paying all the costs.
On consistency you are expected to know that a transaction cannot span services, and to reach for the patterns that replace it: an outbox for atomic publish, idempotent consumers for at-least-once delivery, and sagas with compensating actions where a business process spans services. Proposing a distributed transaction is the answer that ends the round.
How the rounds are structured
Boundary design from a domain description
Given a business, propose services. The score is in the justification and in what you decline to split, not in the number of boxes.
Cross-service consistency
A process spanning two or three services with money or inventory involved. Outbox, idempotency and sagas, with their costs stated.
Failure and resilience
Timeouts, retries with jitter, circuit breakers, and what a service returns when a dependency is unavailable. Degradation as a designed behaviour.
Operational reality
Tracing a request across services, versioning an API with multiple consumers, and deploying a change that spans two services.
What this interview bar tests
Boundaries around capabilities
A service owns its data and changes at its own rate. Boundaries drawn around layers — or around current team shape — produce coupled services that must deploy together.
Consistency without transactions
Outbox for atomic publish, idempotent consumers for at-least-once delivery, sagas with compensation for multi-service processes. Each with its cost named.
Timeouts as design, not configuration
Every call needs a bound, and the bound should shrink as you go deeper so an inner call cannot outlive the outer deadline. A missing timeout is how one slow service takes down four.
Knowing when not to split
A modular monolith with clean internal boundaries beats premature microservices. Candidates who say this unprompted are usually the ones who have operated both.
A preparation plan that works
- 1Take a domain you know and draw the boundaries twice — once by capability, once by technical layer — then articulate why the second is worse. Doing this makes the justification fluent rather than theoretical.
- 2Work one multi-service process end to end with compensation: what happens when step three fails after steps one and two committed. This is the saga question and it is asked constantly.
- 3Write out a timeout budget for a three-deep call chain, with the inner bounds smaller than the outer. Most candidates have never done this and it is immediately visible.
- 4Prepare a position on when you would not use microservices, with a specific instance. It is the question that most reliably separates experience from reading.
Questions you should expect
Order service and inventory service both need to be updated. How?
Not with a distributed transaction. Either one service owns the invariant and the other is notified — order reserves through inventory synchronously and inventory is authoritative — or you run a saga: reserve, then on failure of a later step issue a compensating release. Say which you chose and what the user-visible consequence of the intermediate state is, because that is the real cost.
A downstream service starts responding in 30 seconds instead of 50 milliseconds. What happens to you?
Without a timeout, your threads or connections accumulate on that call until your own service is exhausted, and the failure propagates to your callers — one slow dependency becoming four outages. With a timeout plus a circuit breaker, you fail fast, shed load, and degrade to whatever partial answer is useful. Naming the degraded behaviour is the senior part of the answer.
How do you decide a service is too small?
When it cannot change independently — every meaningful change requires a coordinated deploy with its neighbour — or when it owns no data of its own. Both indicate the boundary was drawn around a layer rather than a capability, and the fix is usually to merge rather than to add orchestration.
Why not just use a monolith?
Often you should, and saying so is a strong signal. Microservices buy independent deploy and scaling at the cost of network failure, distributed consistency, cross-service debugging and multiplied operations. They pay off when teams genuinely need to ship independently; they are expensive when the real problem was module boundaries inside one codebase.
What gets candidates rejected
- Proposing a distributed transaction across services
- Drawing boundaries around technical layers or current team structure
- Services with no timeout on outbound calls
- Describing sagas as "two-phase commit but better" rather than as a different trade-off
- Enthusiasm for microservices with no account of what they cost
- Shared database between services, which forfeits independent deployability
- No answer for what a service returns when a dependency is down
What to practise, in order
Transactional outbox implementation
Atomic publish, at-least-once delivery, idempotent consumption and crash recovery — the mechanism behind most cross-service consistency answers.
Webhook event idempotency and ordering
Duplicate and out-of-order delivery between services, with assertions on final state.
Marketplace escrow payment hold and release
A multi-step money process with compensation — the saga question as runnable code.
Connector record reconciliation sync
Two systems that must converge despite partial failure and retries. Reconciliation as a first-class design concern.
FAQ
Do I need Kubernetes and service mesh knowledge?
Working familiarity usually suffices. Interviews weight boundaries, consistency and failure far more heavily than mesh configuration, and a candidate strong on mesh features but weak on why a saga exists is answering the easier question.
Is it acceptable to argue against microservices?
Not just acceptable — frequently the strongest answer, provided it is specific. "A modular monolith until teams genuinely need independent deploys, because the consistency and debugging costs arrive immediately and the benefits arrive later" is a position interviewers respect.
How much do I need to know about Kafka specifically?
Enough to reason about delivery semantics and ordering: partition-level ordering only, at-least-once delivery, what a rebalance does to in-flight work, why a commit after processing matters. Broker internals are rarely the differentiator.
What about data duplication across services?
Expected and fine, with a stated owner and a propagation mechanism. The anti-pattern is a shared database, which couples deploys and schemas; duplicated read models fed by events are the normal answer and you should be able to name their staleness cost.