Free lesson · Microservices Interview

How Microservices Get Asked in Interviews - What Interviewers Actually Evaluate

Easy10 min readmicroservicessystem-designdistributed-systems

How Microservices Get Asked in Interviews - What Interviewers Actually Evaluate

This is the lesson I wish someone had given me before my first system design interview at Google. Not the one where I got the offer - the one three years earlier, where I knew more about distributed systems than anyone in the room and still got rejected because I could not show that I knew it in the format the interview required.

I have since conducted over 300 system design interviews at Amazon as a Bar Raiser. I have watched candidates who clearly understood microservices fail because they misread what the interview was testing, and I have watched candidates with less raw knowledge pass because they understood what the interviewer was actually evaluating.

This lesson gives you the evaluation lens. Once you have it, every subsequent module in this course will land differently - because you will be absorbing each pattern through the question "how do I demonstrate judgment about this in 45 minutes?"

The Interview Is Not a Knowledge Test

This is the most important reframe in the entire course.

When an interviewer says "design a food delivery platform" or "architect a notification system that serves 10 million users," they are not testing whether you can recite the twelve-factor app methodology or name five microservices patterns. They already know you have read the blog posts. Everyone has read the blog posts.

They are testing four things, and each one is evaluated independently.

The Four Evaluation Dimensions

graph TD
    A["System Design Interview\nEvaluation Framework"] --> B["Decomposition\nJudgment"]
    A --> C["Tradeoff\nArticulation"]
    A --> D["Failure\nAnticipation"]
    A --> E["Scope\nManagement"]
    
    B --> B1["Can you identify\nservice boundaries?"]
    B --> B2["Can you justify\nwhy here and not there?"]
    
    C --> C1["Can you name what\nyou are trading away?"]
    C --> C2["Can you propose\nalternatives?"]
    
    D --> D1["Can you anticipate\nwhat goes wrong?"]
    D --> D2["Can you design for\nfailure unprompted?"]
    
    E --> E1["Can you prioritize\nwhat to design first?"]
    E --> E2["Can you go deep\nwithout losing breadth?"]

This diagram shows the four evaluation dimensions in a system design interview. The first is Decomposition Judgment - whether you can identify service boundaries and justify them. The second is Tradeoff Articulation - whether you can name what you are trading away and propose alternatives. The third is Failure Anticipation - whether you can anticipate failure modes and design for them without being prompted. The fourth is Scope Management - whether you can prioritize what to design first and go deep without losing breadth.

Let me break each one down.

Dimension 1 - Decomposition Judgment

The interviewer gives you a system. At some point - either because you propose it or because they steer you toward it - you will need to decide how to decompose it. This is where most candidates produce their weakest work.

The weak answer sounds like this: "I would have an Order Service, a User Service, a Payment Service, a Notification Service." That is a list of nouns, not a decomposition rationale. It tells me you can identify the entities in the problem, which is table stakes. It does not tell me why those are the right boundaries.

The strong answer sounds like this: "I would separate order management from payment processing because they have different consistency requirements - orders can tolerate eventual consistency for status updates, but payment transactions need strong consistency with idempotency guarantees. These different consistency models mean different database choices and different failure-handling strategies, which argues for separate services with a well-defined contract between them."

The difference is justification. The strong candidate did not just draw a box and label it. They articulated why the boundary exists at this point and what architectural property the separation provides. The boundary is driven by a technical concern (consistency model differences), not by a domain noun.

Interview: What I look for as a Bar Raiser: When a candidate proposes a service boundary, I immediately ask "why there?" The candidate who says "because Order is a separate domain concept" gets a weaker signal than the candidate who says "because the order lifecycle and the payment lifecycle have different consistency, availability, and scaling requirements." The first answer is definitional. The second answer is architectural.

Module 02 of this course - DDD and Service Decomposition - trains this skill specifically. Every lesson in that module is structured around justifying boundaries, not just identifying them.

Dimension 2 - Tradeoff Articulation

Every architectural decision involves a tradeoff. Microservices versus monolith is a tradeoff. Synchronous versus asynchronous communication is a tradeoff. Saga versus two-phase commit is a tradeoff. Event sourcing versus state-based persistence is a tradeoff.

Interviewers evaluate not whether you picked the "right" answer - there often is no single right answer - but whether you can articulate what you are gaining and what you are giving up.

The weak pattern looks like this: "I would use event-driven architecture because it provides loose coupling." That statement is true and completely unhelpful. It is a benefit without a cost, which means the candidate either does not know the cost or is hiding it hoping I will not ask.

The strong pattern looks like this: "I would use event-driven communication between the order service and the inventory service because they do not need synchronous consistency - the inventory reservation can be eventually consistent as long as we handle the compensation case where a reservation fails after the order is accepted. The tradeoff is increased complexity in failure handling. We need a saga with compensation logic, and we need to design the user experience around the possibility of a delayed rejection. I think that tradeoff is worth it here because the alternative - a synchronous call chain - creates a direct availability dependency between order placement and inventory, which means inventory downtime blocks all orders."

That answer demonstrates three things at once: understanding of the pattern, awareness of the cost, and a judgment call about why the cost is acceptable in this specific context. That is what earns a "strong hire" signal.

Interview: The tradeoff test I use: After a candidate makes a decision, I ask "what is the biggest risk with that choice?" If they can name it immediately and explain how they would mitigate it, strong signal. If they pause and look surprised - as if they had not considered that the decision had a downside - weak signal. Every decision has a downside. The interviewer knows it. The candidate should know it too.

Modules 04 (Communication), 05 (Data Management), and 06 (Resilience) are the modules where you build tradeoff vocabulary across the core microservices decisions.

Dimension 3 - Failure Anticipation

This is where senior-level evaluation separates from mid-level evaluation. At L5, an interviewer is satisfied if you design a system that works under normal conditions and can discuss failure modes when asked. At L6 and L7, the expectation is that you raise failure modes yourself, without being prompted.

The difference looks like this.

L5-level interaction:

Interviewer: "What happens if the payment service is down?" Candidate: "Orders would fail. We could add a circuit breaker to detect the outage and return a degraded response."

L7-level interaction:

Candidate: "One concern with this design is that the order service has a synchronous dependency on payment. If payment goes down, we get cascading failures across the order flow. I would add a circuit breaker with a fallback - when payment is unavailable, we accept the order provisionally and process payment asynchronously when the service recovers. The tradeoff is that we can accept orders we later cannot charge for, so we need a compensation flow for that edge case."

The L7 candidate identified the failure mode, proposed the mitigation, named the tradeoff of the mitigation, and identified the second-order consequence - all without the interviewer asking. That is what "designs for failure" looks like in practice.

Interview: The strongest signal a candidate can send is proactively naming a failure mode in their own design and proposing the mitigation before the interviewer gets there. It tells me the candidate thinks about production reliability, not just happy-path functionality. I look for this explicitly in every L6+ loop.

Module 06 (Resilience and Fault Tolerance) is the module that builds this instinct. Module 08 (Observability) extends it - because anticipating failure is only half the skill; the other half is designing the system so you can detect and diagnose failures when they occur.

Dimension 4 - Scope Management

A system design interview is 45 minutes. A real microservices architecture has hundreds of components. You cannot design all of them. You should not try.

The skill the interviewer evaluates is your ability to identify which parts of the system to design in detail, communicate your prioritisation to the interviewer, and go deep on the parts that matter most - all while maintaining enough breadth that the overall architecture is coherent.

The weak pattern is the candidate who spends 25 minutes designing the API gateway layer in exhaustive detail, then rushes through data management and resilience in the final 10 minutes. They went deep on something that is not architecturally interesting for this particular problem, and they ran out of time for the parts that are.

The strong pattern sounds like this: "There are several components here, but I think the most architecturally interesting parts are the data consistency model between orders and inventory, and the failure handling for the payment flow. I would like to spend most of our time on those. For service discovery and the API gateway, I would use a standard pattern - Kubernetes service discovery with an API gateway for external traffic - and I am happy to go deeper there if you would like, but I think the data layer is where the real design decisions are."

That framing tells the interviewer three things: you can see the whole system, you know which parts have the hardest problems, and you are willing to be explicit about prioritisation instead of trying to design everything equally.

Interview: How to negotiate scope: After your initial decomposition, say explicitly: "I see three areas of significant complexity here - [X], [Y], and [Z]. I would like to focus on [X] and [Y] in depth. Would you like me to go there, or is there a different area you would prefer to explore?" This gives the interviewer the chance to redirect you if they have a specific area they want to probe, and it shows that you can think at the meta-level about where complexity lives.

This skill develops across the entire course, but it is tested most directly in Module 13 (Case Studies), where each case study requires you to make scoping decisions before designing.

How Microservices Questions Differ from General System Design

There is a specific flavour to microservices-focused system design questions, and it is worth understanding how they differ from general system design.

General system design questions often start with a product: "design Twitter," "design a URL shortener," "design a chat application." The evaluation focuses on scalability, data modelling, API design, and performance. Microservices may or may not be relevant - a URL shortener probably does not need them.

Microservices-focused questions tend to start with either a decomposition prompt or a migration prompt:

• "You have a monolithic e-commerce application experiencing scaling problems. How would you decompose it into services?"
• "Design the backend architecture for a food delivery platform. Walk me through your service decomposition."
• "Your company is migrating from a monolith to microservices. How would you plan and sequence the migration?"

graph TD
    A["Microservices Interview\nQuestion Types"] --> B["Greenfield\nDecomposition"]
    A --> C["Migration\nPlanning"]
    A --> D["Failure Mode\nAnalysis"]
    A --> E["Scale\nEvolution"]
    
    B --> B1["Design a system from\nscratch using microservices"]
    C --> C1["Given a monolith,\nplan the migration"]
    D --> D1["Here is an architecture.\nWhat breaks?"]
    E --> E1["This works at 1K RPS.\nWhat changes at 100K?"]

This diagram shows four types of microservices interview questions. Greenfield Decomposition asks you to design a system from scratch. Migration Planning gives you a monolith and asks you to plan the migration. Failure Mode Analysis presents an architecture and asks what breaks. Scale Evolution asks what changes as load increases from 1,000 to 100,000 requests per second.

These question types emphasise different skills:

Greenfield decomposition tests Dimensions 1 and 2 most heavily - your ability to identify boundaries and articulate tradeoffs. Module 02 is the primary preparation for this.

Migration planning tests sequencing judgment, risk assessment, and organisational awareness. Module 03 is dedicated to this question type. It is also the question type where candidates with production migration experience have the biggest advantage - and where the exercises in Module 03 provide the closest simulation of the real interview prompt.

Failure mode analysis tests Dimension 3 - your ability to anticipate what goes wrong and design for resilience. Modules 06 and 08 prepare you for this. This question type is also where interviewers test depth: they will keep probing ("what if that fallback also fails?") until they find the boundary of your reasoning. The candidate who can go three levels deep - the primary failure, the fallback failure, and the operational response when both fail - demonstrates the kind of production-hardened thinking that distinguishes a senior engineer from someone who has only built systems that have not broken yet.

Scale evolution tests whether you understand what changes at scale - not just "add more instances," but the organisational, operational, and architectural shifts that happen when a system grows from a handful of services to hundreds. Module 12 is designed specifically for this. A common form of this question is "your architecture works for a startup. Now you have 500 engineers and 200 services - what breaks?" The answer touches governance, discoverability, platform engineering, and cost management - concerns that do not exist at small scale but dominate at large scale.

The Evaluation Rubric You Should Carry Into Every Module

As you work through this course, keep these four questions in mind for every pattern, every strategy, every architectural decision:

1. How does this affect service boundaries? If I use this pattern, does it create coupling between services that should be independent? Does it reinforce the boundaries I have drawn?

2. What am I trading away? Every pattern has a cost. What is the complexity cost of this approach? What is the operational cost? What simpler alternative did I reject, and why?

3. What fails? If this component goes down, what is the blast radius? What is my detection strategy? What is my mitigation?

4. Would I explain this to an interviewer proactively, or only if asked? If a pattern is important enough to include in your design, it is important enough to mention its failure modes and tradeoffs without waiting to be asked.

Important: These four questions are the evaluation rubric that interviewers carry in their heads. They will not tell you this rubric. They will simply probe your design and see whether your answers reveal that you are thinking along these dimensions. This course trains you to think along them naturally - so that by the time you walk into the interview, this reasoning is reflexive, not effortful.

That is the frame. Carry it into Module 01.

Back to Microservices Interview