EvalcueAIMicroservices interview questions
Microservices Interview Questions for Backend Engineers
Microservices interviews are mostly about boundaries and operational cost. Prepare to explain when services should be separated, how they communicate, who owns data, and how failures are contained.
Service-boundary questions
Interviewers want to hear how you decide where one service ends and the next begins.
How do you choose a service boundary?
Draw boundaries around business capabilities that change together and own their data, rather than around technical layers. If two services always deploy together or call each other on every request, the boundary is probably in the wrong place.
When should a monolith stay a monolith?
When the team is small, the domain is still changing, or nothing needs to scale or deploy on its own. A modular monolith with clear internal boundaries is cheaper to run and easier to split later.
Why does each service own its database?
Shared tables couple services through schema changes and hidden dependencies. With one owner per dataset, other services go through its API or events, so the owner can change its storage without breaking anyone.
How do you version a service API?
Make additive, backward-compatible changes by default and have clients ignore unknown fields. Introduce a new version only for breaking changes, run old and new side by side until consumers move, and use contract tests to catch breaks.
Communication and consistency questions
Prepare to compare synchronous calls with events or queues and explain how multi-service workflows remain correct.
Synchronous calls or asynchronous messaging?
Use REST or gRPC when the caller needs an answer now. Use events or queues when the work can happen later or several services react to one change; that decouples their availability at the cost of eventual consistency and harder debugging.
What is a saga?
A sequence of local transactions across services where each step has a compensating action that undoes it if a later step fails. An orchestrator can drive the steps, or services can react to each other's events (choreography).
How do you handle duplicate events?
Assume at-least-once delivery. Include an event ID, have consumers record the IDs they have processed, and write handlers so applying the same event twice changes nothing.
What problem does the outbox pattern solve?
Saving to the database and publishing an event are two separate operations, so one can succeed while the other fails. The outbox writes the event to a table in the same transaction as the data change, and a relay or change-data-capture process publishes it afterwards.
Reliability and operations follow-ups
A microservice architecture adds operational cost. Discuss timeouts, retries, circuit breakers, service discovery, tracing, deployment, configuration, schema evolution, and incident debugging across dependencies.
How do you set timeouts and retries between services?
Every remote call needs a timeout shorter than the caller's own deadline. Retry only idempotent operations, with backoff and jitter, and retry at one layer only so attempts don't multiply down the call chain.
What are circuit breakers and bulkheads?
A circuit breaker stops calling a dependency that keeps failing and fails fast until it recovers. A bulkhead gives each dependency its own pool of threads or connections so one slow dependency can't exhaust them all.
How do you debug a request that crosses many services?
Propagate a trace ID through every call and message and use distributed tracing, such as OpenTelemetry, to see each hop's latency and errors. Put the trace ID in structured logs so you can jump from a trace to the logs.
How do you deploy and roll back services independently?
Keep APIs and schemas backward compatible across a release, use expand-and-contract for database changes, and roll out gradually with canaries or feature flags so a bad version can be rolled back without coordinating with other teams.
Common questions
When should you avoid microservices?
If domain boundaries are unclear, the team is small, independent scaling and deployment are not needed, or operational complexity would dominate the benefits, a modular monolith may be the better choice.
How do microservices handle transactions across services?
Prefer local transactions per service and coordinate workflows with patterns such as sagas, idempotent messages, durable events, and compensating actions rather than relying on broad distributed transactions.