Microservices interviews are really about trade-offs. The architecture solves real problems (independent scaling and deployment) and creates new ones (distributed data, network failures, complexity). The candidate who can reason about both sides stands out. Here are the microservices interview questions that actually get asked, with answers. (See also our system design and backend guides.)
Fundamentals
- Monolith vs microservices — pros, cons, and when to choose each.
- How do microservices communicate — synchronous (REST/gRPC) vs asynchronous (message queues)?
- What is an API gateway and a service registry?
- Service discovery.
Data & consistency
- The database-per-service pattern — why and the challenges.
- How do you handle a transaction across services — the saga pattern?
- Eventual consistency vs strong consistency.
- Event-driven architecture and the outbox pattern.
Resilience & operations
- The circuit breaker pattern.
- Retries, timeouts, and idempotency.
- How do you trace a request across services (distributed tracing)?
- Handling partial failures.
How to prepare
Microservices rounds are design conversations probing trade-offs. Practise reasoning about communication, consistency, and failure out loud. Greenroom runs spoken technical interviews that follow up on your reasoning. Pair it with our system design and backend guides.
Frequently asked questions
What are the most common microservices interview questions?
Common microservices questions cover monolith vs microservices trade-offs, synchronous vs asynchronous communication, API gateways and service discovery, the database-per-service pattern, distributed transactions and the saga pattern, eventual vs strong consistency, event-driven architecture, the circuit breaker pattern, retries/timeouts/idempotency, and distributed tracing for handling partial failures.
What is the difference between a monolith and microservices?
A monolith is a single deployable application where all functionality runs in one process and shares one codebase and database — simpler to build and deploy but harder to scale and evolve at large size. Microservices split functionality into small, independently deployable services with their own data, enabling independent scaling and deployment at the cost of distributed-system complexity, network failures and harder data consistency.
What is the saga pattern in microservices?
The saga pattern manages a transaction that spans multiple services without a distributed lock. Instead of one ACID transaction, it's a sequence of local transactions, each publishing an event that triggers the next step; if a step fails, compensating transactions undo the previous ones. It comes in two styles — choreography (event-driven, no central coordinator) and orchestration (a coordinator directs the steps).
How should I prepare for a microservices interview?
Focus on trade-offs rather than treating microservices as always correct — understand when the operational complexity is justified, how services communicate, how to handle distributed data with patterns like saga, and how to build resilience with circuit breakers and idempotency. Practise reasoning about these trade-offs out loud with a voice-based mock interview that follows up, since these are design conversations.