Microservices interview questions

Boundaries

• How do you decide where one service ends and another begins? Business capability, and data ownership - not technical layers.
• What is a distributed monolith, and how would you recognise one? Services that must be deployed together.
• Should services share a database? No - and being able to explain why (coupling through schema, no independent deploys) matters more than the rule.
• How do you handle data that several services need? Duplication with events, or a clear owner queried through an API.
• What is the cost of getting a boundary wrong, and how do you move one later?

Data and transactions

• Why can you not use a database transaction across services?
• Sagas - a sequence of local transactions with compensating actions. Choreography against orchestration, and the trade-off in traceability.
• Eventual consistency, and how you explain its user-visible effects to a product owner.
• The dual-write problem, and the outbox pattern as the standard answer.
• Idempotent consumers, because messages will be delivered more than once.

Resilience

• Timeouts, retries, and why retries without backoff and jitter make an outage worse.
• Circuit breakers - what state they add and why.
• Bulkheads, so one slow dependency cannot exhaust every thread.
• Graceful degradation - what your service does when a non-critical dependency is down.
• How do you debug a request crossing six services? Distributed tracing with a correlation ID.

Operations

Service discovery, config management, and how you deploy without downtime. Then the honest cost conversation: microservices trade local complexity for operational complexity, and they require real investment in deployment, observability and on-call before they pay back. The messaging layer is covered in Kafka interview questions, and the deployment layer in Kubernetes interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and saying what you have not done reads better than bluffing.
• Mid-level: the same ground plus a service you have owned end to end. Expect follow-ups asking why you made a choice rather than whether you know the syntax.
• Senior: a decomposition or consolidation you led, and what it actually cost. The recall questions get shorter and the judgement questions get longer.

Whatever the level, say your answers out loud rather than reading them. Most of what candidates lose in a microservices interview is lost between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common microservices interview questions?

How to define service boundaries, why services should not share a database, distributed transactions and the saga pattern, resilience patterns such as circuit breakers and backoff, and whether you would choose microservices at all.

How do you handle transactions across microservices?

You cannot use a database transaction, so you use a saga - a sequence of local transactions where each has a compensating action to undo it. Choreography through events is looser coupled; orchestration is easier to trace. The outbox pattern handles the dual-write problem.

Should microservices share a database?

No. A shared schema couples services so tightly that they cannot be deployed or evolved independently, which removes the main benefit. Shared data is handled by giving it a clear owner and exposing it through an API or by duplicating it via events.

When should you not use microservices?

For most new products, because you do not yet understand the boundaries and will likely draw them wrong. They also require real investment in deployment, observability and on-call before paying back, so a small team without that capacity is usually better served by a well-structured monolith.