Microservices Interview Questions

You have read the pattern names, you can recite what a circuit breaker does, and you still cannot tell what a panel is listening for. This section names the four areas interviewers score, in the order they usually probe them. Each one is a judgment question wearing a vocabulary question's clothes.

• Decomposition. Where do you cut, and why there? Interviewers want a boundary drawn along business capability or data ownership, not along technical layers.
• Communication. Synchronous request/response or asynchronous events, and what breaks under each. The answer they want is a tradeoff, not a preference.
• Data. One database per service means no cross-service joins and no distributed transaction. How do you keep the system correct anyway?
• Operations. Deployment, versioning, tracing, and what happens at three in the morning when one service is slow rather than down.

Notice that none of these are about a framework. A candidate who explains why they split checkout from inventory outscores one who lists annotations, every time.

These are the questions that open most microservices rounds, with what the interviewer is checking underneath each.

• How would you split this monolith into services? Checking whether you cut along business capabilities and data ownership, or along controller, service and repository layers. The second answer produces a distributed monolith.
• How do two services talk to each other? Checking whether you can name the cost of each choice: synchronous calls give you a simple mental model and couple availability, asynchronous events decouple availability and give you eventual consistency to explain to a product owner.
• What is a distributed monolith and how do you avoid one? Checking whether you know that services which must deploy together are not really separate.
• How big should a service be? Checking that you resist a number. Size follows the boundary and the team that owns it.
• Do you need an API gateway, and what does it do? Checking whether you can separate routing, authentication and rate limiting from business logic.
• How do services find each other? Checking basic familiarity with service discovery and why hardcoded hosts fail in a scaled environment.

Say the tradeoff out loud in every answer. A panel cannot award points for a comparison you made silently in your head.

This is where interviews are won or lost, because these questions have no clean answer and candidates reach for a memorized one.

• How do you keep data consistent across services? Name the constraint first: there is no cross-service transaction. Then describe a saga, either choreographed through events or orchestrated by a coordinator, and say plainly that the system is eventually consistent and what the user sees in the gap.
• What happens when a downstream service is slow? Timeouts, retries with backoff, and a circuit breaker so a slow dependency does not exhaust your thread pool. Slow is worse than down, and saying so signals production experience.
• How do you make a retry safe? Idempotency. An idempotency key on the write path, so a retried payment charges once.
• How do you handle a partial failure in a multi-step flow? Compensating actions, not rollback. Explain what refunding or releasing a reservation looks like.
• How do you debug a request that touched six services? Distributed tracing with a correlation ID propagated through every hop, plus structured logs and metrics.

A backend engineer interviewing for an L5 platform role at a public cloud vendor got the saga question and answered it in one pass, in pattern vocabulary, with no mention of what the customer would see. The follow-up, what does the order page display during the inconsistent window, is the question that actually decides the round. Prepare the second answer, not just the first.

More question banks by role and topic are collected under interview questions by role.

Reading this list produces recognition, and recognition disappears when a stranger asks the question and waits. The gap between knowing a pattern and explaining it under mild pressure is the whole difficulty of a system-design round, and it only closes by speaking.

Pick one flow you know well, an order placement or a signup, and narrate the full decomposition aloud: the boundary, the communication choice, the consistency story, the failure story. Do it until you stop restarting sentences. You can run these prompts against an AI interviewer that asks follow-ups and lets you answer by voice in mock interview mode, which is closer to the real thing than rereading notes.

Aaron Cao, founder of SubcueAI, built the practice mode around that gap rather than around content delivery. Question lists are freely available everywhere; what candidates lack is repetitions of saying the answer while someone waits. During a real interview the desktop app and the browser extension Side Panel can surface structured prompts as the interviewer speaks, though a rehearsed explanation always beats one you are reading for the first time. What the assistant does and does not do is described on the product overview.