Microservices architecture interview questions, answered
Ask an engineer to "explain microservices" and you get a definition. Ask them "why would you not use microservices here?" and you find out whether they have actually run them. That gap is what a microservices architecture interview is built to probe. The questions are rarely about reciting that services are small and independently deployable; they are about the trade-offs — when a monolith is the better call, how you draw the boundaries between services, how those services talk without turning into a distributed mud ball, and what happens to a transaction that has to span three of them.
This guide walks the microservices interview questions that actually come up, with the answer a strong candidate gives and, more importantly, the follow-up that comes after it. Microservices is a favourite system design topic because every answer opens a door: say "each service owns its own database" and the next question is "then how do you keep an order and its payment consistent?"; say "they communicate over REST" and the next is "what happens when the service you call is down?" The skill being tested is not knowing the vocabulary — it is holding up the architecture under exactly those pushes.
Why microservices questions come up in system design interviews
Microservices sit at the centre of the modern backend, so they surface in two places in a loop: as a direct "tell me about microservices" question in a system design or architecture round, and inside a design when you split a system into services and the interviewer starts pulling on the seams. Either way the test is the same — can you reason about distributed systems, or have you only memorised the word "decoupled"?
The interviewer rarely lets "we'll use microservices" stand on its own. "You've split checkout into an Order service and a Payment service, each with its own database. A customer places an order, the order is saved, and then the payment fails. Walk me through exactly what state the system is in now, and how you stop the customer being charged for an order that doesn't exist — or holding an order that was never paid for." That question — consistency across a boundary you just created — is the one a memorised definition can never survive, and the one microservices questions are really testing.
The rounds on Zynter are modelled on how the loop runs, not scraped from any candidate's recall. What matters for prep is the shape: you state an architecture decision, and the next sentence attacks its weakest point — a failed cross-service call, a data inconsistency, a service you cannot find, or an operational cost you did not price in.
What the interviewer is really testing
A microservices answer is read on the same four dimensions as any design decision. Problem solving — did you justify the split (or the decision not to split) against real requirements, or reach for microservices because they sound senior? Communication — can you explain in one sentence why a database-per-service makes transactions hard and what you do about it? Technical execution — do you handle the failure modes a distributed system creates (partial failure, retries, idempotency), or did you assume the network is reliable? Time management — did you spend your words on the boundaries and the consistency story, not on listing every AWS service by name? Reading this guide teaches the answers; it does not teach you to defend one while someone pushes on the failed payment.
Monolith vs microservices: when is the split worth it?
The first real question is almost always a comparison, because the honest answer is "it depends," and the interviewer wants to hear on what.
A monolith is a single deployable unit: one codebase, one process, one database. Its strengths are the ones teams forget to credit — a simple call is a function call, not a network hop; a transaction is a single database transaction; there is one thing to deploy, test and debug. Its pain shows up with scale of organisation and load: a large team contends on one codebase, you must scale the whole thing to scale one hot path, and one bad deploy takes everything down.
Microservices split the system into independently deployable services, each owning a business capability and its own data. The wins are real: teams ship independently, each service scales and is written in whatever stack fits, and a failure can be contained to one service. The costs are equally real and are where interviews live: a function call becomes a network call that can fail, a transaction now spans services, and you have taken on the full operational weight of a distributed system — service discovery, distributed tracing, versioned APIs, and many more things that can break at 3 a.m.
Say the judgement out loud: start with a well-structured monolith; split out a service when a specific part has a different scaling profile, a different rate of change, or a team that needs to own it independently — not because microservices are the default. Reaching for microservices on a greenfield project with a three-person team is a red flag, and a strong candidate says so.
| Monolith | Microservices | |
|---|---|---|
| Deploy | one unit, all at once | per service, independently |
| A typical call | in-process function call | network call (can fail, adds latency) |
| A transaction | one DB transaction (ACID) | spans services → saga / eventual consistency |
| Scaling | scale the whole app | scale the hot service only |
| Failure blast radius | one bad deploy → whole app | contained to a service (if you built it that way) |
| Best when | small team, early product, tight transactions | large org, independent teams, differing scale profiles |
System Design
HLD · Core concept
Defend "monolith or microservices?" out loud
How do you decompose a system into services?
If you say "microservices," the natural follow-up is "how do you decide where one service ends and the next begins?" The wrong answer is "by technical layer" (a users-service, a database-service, a utils-service) — that creates services that must all change together, which is the worst of both worlds.
The answer interviewers want is decompose by business capability / domain, using the ideas from domain-driven design:
- By business capability — each service owns one thing the business does: Orders, Payments, Inventory, Shipping, Notifications. A new feature touches as few services as possible.
- Bounded context — a service owns its own model of a concept. "Customer" in the Billing service and "Customer" in the Support service are deliberately different models; forcing one shared model couples everything.
- High cohesion, loose coupling — things that change together live together; services depend on each other as little as possible, and never reach into each other's database.
- The right size — "micro" is a trap. A service should be big enough to own a capability end-to-end and small enough for one team to understand it. "Each service is owned by one team and owns its data" is a better yardstick than any line count.
The sentence that scores: I split by business capability, not technical layer, so that a change to how we take payments touches the Payment service and nothing else — a boundary drawn right is one that a single team can change without coordinating a release with four others.
How do microservices communicate?
Services have to talk, and the choice between synchronous and asynchronous communication is one of the most common follow-ups, because it decides how failure propagates.
Synchronous (request/response) — one service calls another and waits: REST over HTTP, or gRPC for lower-latency internal calls. Simple and easy to reason about, but it creates temporal coupling: the caller is only as available as the callee, and a slow downstream service makes the caller slow too. Chains of synchronous calls are where latency and cascading failures come from.
Asynchronous (event-driven) — a service publishes an event to a message broker (Kafka, RabbitMQ, SQS) and moves on; interested services consume it on their own time. This decouples services in time: the publisher does not care if a consumer is momentarily down, and load spikes are absorbed by the queue. The cost is complexity — eventual consistency, out-of-order and duplicate messages to handle, and a message broker to operate.
The pairing that reads as experience: use synchronous calls when the caller genuinely needs an answer right now (a price before showing a checkout page) and events when a service just needs to tell the world something happened (an order was placed) and let others react — and prefer events at the boundaries where a hard dependency would hurt availability.
What are the API gateway and service discovery for?
Two components come up so reliably they are almost always worth naming before you are asked.
API gateway — a single entry point that sits in front of the services and handles the cross-cutting concerns you do not want in every service: routing a request to the right service, authentication and authorisation, rate limiting, TLS termination, and sometimes aggregating several service calls into one response for a client. Without it, every client would need to know the address of every service and re-implement auth. The trap to acknowledge: the gateway must not become a smart monolith of business logic — it routes and enforces policy, it does not do the work.
Service discovery — in a dynamic environment services come and go and their network addresses change constantly (containers restart, autoscaling adds instances). Discovery is how a service finds a healthy instance of another: services register themselves in a registry (like Consul, etcd or the platform's built-in discovery) and look each other up by name instead of hard-coded IP. This is also where load balancing between instances happens.
Say it crisply: the gateway is the front door for outside traffic — one place for auth, routing and rate limiting; service discovery is how services find each other on the inside when addresses are changing under them.
System Design
HLD · Core concept
Walk the gateway, discovery and saga out loud
How do you manage data and transactions across services?
This is the hard core of a microservices interview, and the follow-up from the opening scenario lands here.
The rule is database per service: each service owns its data and no other service touches its database directly. This is what makes services independent — you can change the Payment service's schema without coordinating with anyone. But it breaks the thing a monolith gave you for free: a single ACID transaction across the whole system. You cannot BEGIN TRANSACTION across the Order and Payment databases.
The answer is the saga pattern: model a cross-service operation as a sequence of local transactions, each with a compensating action that undoes it if a later step fails. Place an order → reserve inventory → take payment; if payment fails, run the compensations — release the inventory, cancel the order. The system is never in a single global transaction; it is eventually consistent, moving through intermediate states toward a consistent end. Two ways to coordinate a saga:
- Choreography — each service listens for events and reacts, publishing its own event when done. No central coordinator; simple for short sagas, but the overall flow is spread across services and hard to follow as it grows.
- Orchestration — a central orchestrator tells each service what to do next and triggers compensations on failure. The flow lives in one place and is easier to reason about and monitor; the orchestrator is one more thing to build and keep available.
Two more points that score: two-phase commit (2PC) exists but is usually rejected in interviews for microservices because it is a blocking, availability-killing protocol that couples services tightly; and because retries are inevitable in a distributed system, operations must be idempotent — processing the same "take payment" message twice must not charge the customer twice.
The sentence that wins the scenario: I'd model checkout as a saga — reserve inventory, take payment, confirm order, each a local transaction with a compensating undo — so a failed payment triggers "release inventory, cancel order," and I'd make each step idempotent so a retry can't double-charge; the customer sees "order failed," not a charge for an order that doesn't exist.
How do microservices stay resilient when a service fails?
In a monolith a failure is an exception; in microservices a failure is a network event — the service you call might be down, slow, or unreachable, and the interviewer wants to know you have planned for it.
- Timeouts — never wait forever on a downstream call; a missing timeout is how one slow service hangs every thread in the caller.
- Retries with backoff — retry transient failures, but with exponential backoff and jitter so you do not stampede a recovering service, and only for idempotent operations.
- Circuit breaker — after a downstream service fails repeatedly, "open the circuit" and fail fast (or serve a fallback) instead of hammering it; probe periodically and close the circuit when it recovers. This is the fix for cascading failure, where one dead service drags down everyone who calls it.
- Bulkhead — isolate resources (thread pools, connection pools) per dependency so one struggling downstream cannot exhaust the resources the rest of the app needs.
- Graceful degradation — when a non-critical service is down, return a sensible partial response (hide the "recommended for you" row) rather than failing the whole page.
And because a request now spans many services, observability is not optional: distributed tracing (a correlation ID threaded through every hop) is how you answer "which of the eight services made this request slow?" — a question a monolith's single stack trace answered for free.
The framing to state plainly: a monolith fails loudly in one place; microservices fail partially, over the network, in ways the caller must expect — so timeouts, retries with backoff, a circuit breaker and tracing aren't extras, they're the cost of admission.
How to talk about microservices in an interview
The probes from every section rhyme. Master these five and you can defend a microservices decision in any design, not just this checklist.
- "Monolith or microservices for this?" → A well-structured monolith unless a part has a distinct scaling profile, rate of change, or team that must own it; microservices buy independence at the price of distributed-system complexity, so I split deliberately, not by default. (problem solving)
- "How do you draw the service boundaries?" → By business capability and bounded context, not technical layer, so a change touches one service and one team — high cohesion inside, loose coupling across, each service owning its own data. (communication)
- "Service A calls Service B synchronously and B is down — what happens?" → Timeout fast, retry transient failures with backoff, and a circuit breaker to fail fast and stop a cascade; where a hard dependency would hurt availability, I'd use an event instead of a blocking call. (technical execution)
- "Each service has its own database — how do you keep an order and its payment consistent?" → A saga of local transactions with compensating actions and idempotent steps, accepting eventual consistency, rather than a distributed transaction (2PC blocks and couples). (technical execution)
- "A request is slow and it touched six services — how do you find the culprit?" → Distributed tracing with a correlation ID through every hop, plus per-service metrics and logs; that's the monolith's stack trace, rebuilt for a distributed system. (problem solving)
Each maps to a debrief dimension. Reading them teaches the answers; it does not teach you to deliver them while someone interrupts with "but now the orchestrator is down" — that only comes from saying them out loud.
How to prepare: a short plan
You do not need to memorise a reference architecture. You need the trade-offs automatic, so when a design splits into services you can defend every seam.
- Day 1: Nail the monolith-vs-microservices judgement and decomposition (business capability, bounded context) until you can argue both sides and say when you would not split.
- Day 2: Drill communication (sync vs async), the gateway and discovery, and the data story — database per service, the saga pattern, choreography vs orchestration, idempotency. This is where the follow-ups live.
- Day 3: Drill resilience (timeouts, retries, circuit breaker, bulkhead) and observability (tracing), then put it together in a real design — an e-commerce checkout, a ride-share, a streaming backend — out loud, timed, with someone pushing on the failed cross-service call.
This explainer feeds the broader Top 25 system design interview questions — a microservices decision sits inside most of them, so getting these trade-offs automatic pays off across the whole list.
Frequently asked questions
What is the difference between a monolith and microservices?
A monolith is a single deployable application: one codebase, one process and typically one database, where an internal call is a function call and a transaction is a single database transaction. Microservices split the same system into independently deployable services, each owning a business capability and its own data, communicating over the network. The monolith is simpler to build, test, deploy and keep transactionally consistent, which makes it the right choice for small teams and early products. Microservices let independent teams ship and scale their service separately and contain failures, but at the cost of distributed-system complexity — network calls that can fail, cross-service transactions, and operational machinery like service discovery and tracing. The interview-worthy answer is that you start with a monolith and split deliberately, not by default.
How do you decide how to split a system into microservices?
You decompose by business capability and domain rather than by technical layer. Each service should own one thing the business does — Orders, Payments, Inventory — along with its own data, so that a change to a capability touches as few services as possible. Domain-driven design's idea of a bounded context helps: a service owns its own model of a concept, and you deliberately avoid forcing a single shared model across services because that couples them. The guiding principles are high cohesion (things that change together live together) and loose coupling (services depend on each other as little as possible and never share a database). A good practical test is that one team can own a service and change it without coordinating a release with several others.
What is the saga pattern and why is it needed?
Because each microservice owns its own database, you lose the ability to run a single ACID transaction across the whole system — you cannot wrap an order insert and a payment charge in one database transaction when they live in different services. The saga pattern solves this by modelling a cross-service operation as a sequence of local transactions, each with a compensating action that undoes it if a later step fails. For a checkout, that is reserve inventory → take payment → confirm order, and if payment fails the compensations run — release the inventory and cancel the order. The system is eventually consistent rather than instantly consistent. Sagas are coordinated either by choreography (services react to each other's events, no central coordinator) or orchestration (a central orchestrator directs each step and triggers compensations).
Synchronous or asynchronous communication between microservices?
Synchronous communication (REST or gRPC request/response) is simple and easy to reason about, but it creates temporal coupling: the caller is only as available as the service it calls, and a slow downstream service makes the caller slow, which is how cascading failures start. Asynchronous communication (publishing events to a broker like Kafka, RabbitMQ or SQS) decouples services in time — the publisher does not care if a consumer is briefly down, and a queue absorbs load spikes — at the cost of eventual consistency and having to handle duplicate or out-of-order messages. A good rule is to use synchronous calls when the caller genuinely needs an immediate answer and events when a service just needs to announce that something happened and let others react, preferring events at boundaries where a hard dependency would hurt availability.
What is a circuit breaker in microservices?
A circuit breaker is a resilience pattern that stops a failing downstream service from dragging down everything that calls it. It works like an electrical breaker: while calls to a service are succeeding the circuit is closed and traffic flows, but after a configured number of failures the breaker "opens" and the caller fails fast — returning an error or a fallback immediately instead of waiting on timeouts and piling more load onto the struggling service. Periodically the breaker lets a probe request through, and if the service has recovered it closes again. Combined with timeouts, retries with exponential backoff, and bulkheads that isolate resources per dependency, the circuit breaker is the standard defence against cascading failure in a distributed system.
How do I practise a microservices system design interview out loud?
Reading about the saga pattern is not the same as defending your boundaries while an interviewer pushes on a failed cross-service payment. On Zynter, the HLD track runs live voice rounds modelled on how real system design loops run — you talk through an architecture on a shared canvas, and a voice interviewer follows up one question at a time ("the payment service is down, what happens to the order?", "now the orchestrator fails mid-saga"), then gives you a debrief on problem solving, communication, technical execution and time management. The score is a practice signal, not a hiring decision.
Practise it on Zynter
You can define microservices. The round is won on defending the failed payment across two services out loud.
Pick an HLD system design round, split your design into services on the canvas, and defend it out loud to a voice interviewer that keeps asking "each service has its own database — how do an order and its payment stay consistent?" and "the service you just called is down — now what?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).
Practise an HLD system design round →
Browse all interview tracks
Top comments (0)