The Microservices System Design Interview: A Six-Step Framework

A short disclosure: I created Grokking the System Design Interview and, more recently, Grokking Microservices for System Design Interviews, so I have a bias toward "take a course" as the answer. Everything below is complete and useful on its own. It comes from building those courses and from running system design interviews for years.

Ask an engineer to explain microservices and most of them do fine. Ask the same engineer to design a service architecture in 45 minutes, out loud, in front of someone grading them, and something different happens. The vocabulary arrives. The judgment does not.

That gap is the whole interview. Interviewers are not checking whether you can define a circuit breaker. They are checking whether you know what one costs, when it is the wrong tool, and what the user sees when it opens.

This guide is the method I teach for closing that gap: what the round actually grades, a six-step framework with minute budgets that fits a 45-minute slot, a complete worked walkthrough, the four follow-ups that decide your grade, and the twelve answers that mark a candidate as junior.

What the Microservices Interview Actually Tests

A microservices question looks like any other system design question. "Design the order processing system for an e-commerce company." "Design the backend for a food delivery platform." "You have joined a company with a twelve-year-old monolith and the CTO has announced a move to microservices, design the migration."

Underneath, three things are being graded, and only one of them is knowledge.

Do you know what distribution costs? Splitting one application into services buys you deployment autonomy: each team ships when it wants without waiting for anyone. It costs you latency, consistency, and operational surface. A candidate who names the benefit without the cost has told the interviewer they have read about microservices rather than run them.

Can you defend a line? Every box you draw is a claim that this thing should deploy separately from that thing. The interviewer will push on at least one. "Why is Payments its own service?" has a real answer (PCI scope stays small, its reliability profile is different from everything else) and a fake one ("separation of concerns").

Do you volunteer failure? This is the strongest single habit in the game. Every time you draw an arrow between two services, say what happens when that call is slow or fails, before anyone asks. Candidates who do this consistently read as senior almost regardless of what else they get right.

Notice that none of the three requires you to know a technology. They require you to have opinions with prices attached.

Why a Fixed Order Beats Improvising

Under pressure, structure is what survives.

A memorized framework does two jobs. It keeps you from skipping anything load bearing, and it puts the decisions in dependency order so each step's output feeds the next one. Think of it like a build pipeline: you cannot run a later stage before the earlier stage produces its output. You cannot decide sync or async on an edge before you know which services exist. You cannot know which services exist before you know what the system has to do.

The six steps below are that order. The minute budgets assume a 45-minute round with about 35 minutes of actual design time.

The Six Steps

Step 1: Requirements and scale (5 minutes)

Start with functional requirements, the things the system must do. Write them as a short list of verbs. Then get the non-functional requirements, which are the numbers you will actually use later: requests per second, data sizes, latency expectations.

For this architecture especially, ask about team and organizational context if the question offers any, because that is what decides how much splitting is justified. Three hundred engineers justifies real service boundaries. Twelve engineers usually does not.

Close the step by stating the two or three requirements that will drive the design: "the hard parts here are the payment's correctness and the fan-out on order events." Fan-out means one fact has to reach many consumers.

Interviewers consistently cite skipping or rushing this step as the most common candidate failure. Five minutes of requirements buys you the right to say "no" later, with evidence.

Step 2: Service boundaries and data ownership (5 to 7 minutes)

Draw the services by capability, not by noun. A capability is something the business does, like taking payments. A noun is just a thing, like "User."

This matters more than any other decision on the board. Entity-named services (User, Order, Product, Payment, Cart) look tidy and produce an architecture where no operation completes without a five-hop tour across the network. Capability-named services (Cart and Checkout, Orders and Fulfillment, Payments, Inventory, Notifications) keep the work that changes together in one place.

Say the justification out loud as you draw each box: what it owns, why it is separate, and which single service is allowed to write each piece of data. One writer per datum is the rule, and stating it as you draw is worth real points.

Fewer boxes with defended lines beat many boxes with none. And if the system plausibly should not be microservices at all at the stated scale, say so here. Propose the modular monolith, which is one deployable app with strict module boundaries inside it, then note that you will design the service version since that is the exercise. That one sentence is a scoring event.

Step 3: Communication per edge (5 minutes)

Take each arrow in your drawing and decide sync or async. The question is not a matter of taste. It is: does the caller need the answer to proceed? Synchronous means the caller stops and waits. Asynchronous means it hands the work off and keeps going.

Then cover the rest of each edge in one sentence apiece:

• Protocol. REST for traffic from outside clients, gRPC between your own services because it is a faster binary protocol built for that job.
• Events published where the facts happen, fat enough to avoid callbacks. A fat event carries the full details instead of just an ID, so consumers never have to call back and ask for more.
• A gateway at the front, meaning one entry point that receives client traffic and routes it. Authentication happens here so services do not each reimplement it.
• A coordination style for any multi-step flow, so the interviewer knows whether one service directs the flow (orchestration) or the services react to each other's events (choreography).

The sentence that scores in this step: "every service off the request path is latency and availability reclaimed, and next quarter's fraud consumer subscribes without Checkout changing."

Step 4: Data and consistency (7 to 10 minutes)

This is the depth step, and it is where senior signal concentrates. Budget for it, and slow down when you get here.

First find every place where two services' data must agree. Then apply the machinery deliberately, naming each piece:

• Sagas for transactions that span services. A saga is a sequence of local transactions, each with an undo step. Name each compensation. Put the riskiest step last.
• The outbox on every seam where you write to your database and then publish an event. An outbox is a table where you save the event in the same transaction as the data change, so a separate relay can publish it afterward. Without it you have a dual write, and dual writes lose data.
• Idempotency on every handler and every payment, so the same message arriving twice cannot charge the customer twice.
• Read models for queries that need data from more than one service. A read model is a read-only copy shaped for one query and fed by events.
• An honest sentence about what is eventually consistent and who sees it. Eventually consistent means the copies agree after a short delay, not instantly. Then add read-your-writes where the user would notice, so a customer always sees the order they just placed.

Step 5: Failure handling (5 to 7 minutes)

Ideally this step is already spread across the others, because raising failure as you draw each arrow is the habit that separates candidates. Use this step to sweep up what remains.

Pick the two scariest edges and run them end to end: the timeout number, the retry discipline, the breaker and bulkhead, and what the user sees. A circuit breaker stops calling a dependency that keeps failing. A bulkhead caps how much of your capacity one dependency is allowed to consume.

One full failure walkthrough beats five pattern names. The walk looks like this:

1. You draw an arrow between two services.
2. What happens when this call is slow or fails?
3. A timeout, with a stated number, taken from the dependency's p99 latency.
4. A retry, only if repeating the work is safe, with jitter so retries do not all land at once.
5. A breaker that opens after repeated failures.
6. A fallback or reduced response.
7. What the user sees on screen.

That last step is the one candidates skip, and it is the one that proves you have shipped something.

Step 6: Operations (3 to 5 minutes, often compressed)

One paragraph that grounds the design in reality. Canary deploys send the new version a small slice of traffic first, with automated metric comparison before a full rollout. Symptom-based alerts fire on what users feel, like error rate, instead of on CPU. A correlation ID is one ID attached to a request so you can follow it across every service it touches. mTLS means both sides prove who they are with certificates, and least privilege means each service gets only the permissions it needs.

If time is gone, one sentence acknowledging the step exists still banks most of its value: "operationally, canaried deploys, RED dashboards, traces end to end." RED stands for rate, errors, and duration, the three numbers you watch per service.

Three Meta-Skills That Sit on Top

The steps are the map. These three are how you drive.

Announce the plan. Say it in the first minute: "I'll get requirements, draw boundaries, then communication, then go deep on consistency and failure." It costs ten seconds, signals structure, and lets the interviewer redirect you early if they want depth somewhere specific.

Follow the interviewer's energy. When they pull toward consistency, go. The framework is your map, not your script. Fighting the interviewer for the agenda loses exactly the points that structure was supposed to win.

Timebox visibly. If boundaries are eating minutes, say "I'll fix these two services and revisit if needed" and move on. An unfinished consistency step costs more than an imperfect boundary step.

A Full Walkthrough: An E-commerce Order System

Here is the framework applied end to end, on the single most common microservices question in the loop.

"Design the order processing system for an e-commerce company. Browsing is handled elsewhere; you own everything from 'add to cart' through payment, fulfillment, and customer notifications. Mid-size: about two million orders a month, 300 engineers across the company. 45 minutes."

Minutes 0 to 5, requirements. Functional scope: cart management, checkout with payment, order lifecycle through fulfillment, notifications, order history.

Now size it. Two million orders a month is roughly 45 orders a minute on average. Assume 10x at peak, so about 8 orders a second. Cart traffic follows browsing, so it may run 100x higher than order traffic.

That is not huge, and saying so is a calibration point. Calibration means showing you can size a system before you design it. Say it plainly: "the scale is moderate; the hard parts here are correctness, money must never be charged twice or orders lost, and the fan-out of order events to everything downstream." Then bank the org fact: 300 engineers justifies real service boundaries.

Minutes 5 to 12, boundaries. Five services, each justified as you draw it.

• Cart and Checkout owns carts and order placement. It keeps event-fed price copies and snapshots the price into the order at purchase time.
• Orders and Fulfillment owns the post-purchase lifecycle, everything that happens after the money is taken.
• Payments is isolated for PCI scope and for its reliability profile. PCI scope is the part of the system that touches card data and has to pass card-industry audits. Keeping that part small keeps the audit small.
• Inventory owns stock and reservations. Its write pattern diverges from everything else: tiny, frequent writes that fight over single items.
• Notifications is purely reactive. It only listens to events, so it separates naturally.

Two extra sentences earn points here. First, there is no User service. Each context owns its own slice of user data, keyed by ID, and auth lives at the edge. Second, state data ownership as you draw each box.

Minutes 12 to 18, communication. Clients hit a gateway, and traffic from outside is REST. Internal calls are gRPC. The critical path of checkout is synchronous and exactly three hops: Checkout to Inventory for the reservation, Checkout to Payments for the charge. Everything downstream of "order placed" is a fat event on a topic, consumed independently by Fulfillment, Notifications, and Analytics.

Minutes 18 to 28, consistency. This is the deep dive.

Walk checkout as an orchestrated saga, meaning one service drives the steps in order. The forward path has four steps: create the order as pending, reserve stock with a 15-minute expiring reservation, charge the card, trigger fulfillment. Compensations run in reverse when a step fails: release the reservation, then cancel the order. The charge sits last on purpose, because it is the riskiest step.

Three mechanisms hold it together, and each one has a name you should say out loud:

• Every write-then-publish seam gets an outbox. "The order row and its event commit in one transaction; a relay publishes; at-least-once delivery, so every consumer dedupes."
• The charge carries an idempotency key minted at order creation, so a timeout plus a retry can never double-charge.
• Order history is a materialized view fed by the same events, with read-your-writes for the buyer's own order.

Minutes 28 to 35, failure. Pick the two scariest edges and run them.

Payments down, in ninety seconds: a 1-second timeout taken from the p99 latency. One retry with jitter under the same idempotency key. The breaker opens after repeated failures. The bulkhead contained the threads the whole time, so Payments cannot starve the rest of Checkout. Then the product choice: fail cleanly with the cart saved, or accept orders as payment_pending with a deferred-charge queue and a dead letter queue behind it.

Broker down, the second run: Checkout still completes, because the outbox holds events durably until the relay can publish. Consumers catch up afterward. The only visible degradation is delayed emails. Name that out loud, because it is the payoff of the outbox choice.

Minutes 35 to 38, operations. Canary deploys with automated metric comparison. RED dashboards per service. Symptom-based SLO alerts. One trace ID following a request from the gateway through every event it triggers. mTLS and least privilege.

That leaves minutes for follow-ups, and that is by design.

The Follow-Ups That Decide the Grade

The follow-up conversation is where senior scoring concentrates. Expect these four on almost any question of this shape.

"Two customers race for the last unit." The reservation is a local transaction inside Inventory, and Inventory is the one source of truth. First commit wins, second customer gets an honest out-of-stock. Strong consistency at the contention point, eventual everywhere else. Stock counts on the browse page can lag. The reservation cannot.

"Where exactly can an order be lost?" Walk the seams one at a time. The request path is synchronous with explicit errors. The order-to-event seam is outbox-atomic, so the row and the event commit together. Event-to-consumer is at-least-once, with dead letter queues that alert on depth. Then state the conclusion you have earned: there is no silent-loss seam, and you named a mechanism at every one of them instead of waving.

"Why not fewer services? More?" The boundaries follow three things: team ownership, divergent profiles (PCI, inventory write patterns), and change patterns. At 300 engineers this count is conservative. If release contention stayed low, merging Cart and Checkout with Orders would be the first consolidation candidate.

"What breaks first at 10x?" Have your own answer before they ask. Inventory reservation contention on hot items goes first, then the payment provider's rate limits. Both have named treatments: short reservations and per-item sharding for the first, multiple providers behind an abstraction with a breaker per provider for the second.

Twelve Answers That Sound Junior, and Their Fixes

Nearly every red flag in this interview is one of three shapes: a benefit stated without its cost, a mechanism named without its consequence, or a slogan where a judgment was requested. Here are the twelve highest-frequency failures.

1. "Microservices, because they scale better." Scale on its own is not a reason, and per-request performance gets worse, not better. Fix: "Microservices solve organizational problems: independent deployment for multiple teams. What they cost is distribution: latency, consistency, operations."

2. Monolith used as a synonym for legacy mess. Strong teams run one on purpose, and the industry has spent recent years consolidating services back into fewer, bigger ones. Fix: bring up the modular monolith yourself, then name the evidence that would justify splitting it.

3. One service per noun: User, Order, Product, Payment. The boundary failure that shows up most often in interviewer write-ups. No operation completes without a five-hop tour. Fix: split by capability, not entity, and state who owns which data as you draw each box.

4. Many service boxes, one shared database cylinder. The picture tells the interviewer the boxes are decorative. Fix: one private store per service, cross-service needs met with events and owned copies. Then say the coupling reason out loud, not just the rule.

5. "We'd add retries" as the universal failure answer. With no backoff, jitter, budget, or idempotency caveat, the interviewer hears "I would amplify your outage threefold." Fix: the twenty-word version. Backoff, jitter, budget, retries at one layer only, idempotent operations only, breaker for sustained failures.

6. A payment retry with no idempotency story. The most dangerous single omission available to you, because the harm is concrete and the follow-up is always loaded: "the timeout fired but the charge landed." Fix: an idempotency key, minted once per logical action, stored atomically with the effect.

7. "It returns an error and we show an error message" for every failure. This ignores the slow case, and the slow case is what takes sites down. Fix: distinguish fast, slow, and ambiguous failures, then run the loop: detect, respond, contain, degrade.

8. Everything synchronous, or everything events. Both are ideologies, not designs. Fix: ask the one question per arrow. Does the caller need the answer to proceed?

9. "We'd use Kafka" with no job attached. Technology named by prestige. Same failure as proposing a service mesh for five services. Fix: name what the tool does on that specific edge, and what it costs.

10. Calling a saga compensation a "rollback." Committed local transactions cannot roll back. A refund is a new business action, and some steps compensate only approximately. Fix: talk about compensations as business actions, put the riskiest step last, and name isolation as the missing letter. A saga gives you atomicity, consistency, and durability, but not isolation.

11. "Kubernetes handles it." For failures, consistency, or fallbacks, it does not. It restarts pods and reschedules workloads, and that is the extent of it. Fix: consume the platform's real guarantees by name and own everything above them.

12. "We'd monitor it and roll back if something goes wrong." Nothing in that sentence can be checked, and unfalsifiable is what junior sounds like in the operations round. Fix: a canary with automated metric comparison, symptom-based SLO alerts, trace IDs end to end, and a named detection-to-rollback path with times attached.

Read the twelve again and every fix is the same move: attach the cost, the consequence, or the evidence. The sentence shape is "X, because Y, and it costs Z, so I'd watch for W." Applied consistently, that shape is most of what senior sounds like in this interview.

Free Download: The Microservices Interview Cheat Sheet

Everything above, compressed to something you can review on the morning of the interview. Thirteen pages:

• The six steps with minute budgets, on one page
• Boundaries, communication, the consistency toolkit, and the failure walk
• Ten worked case studies, one card each: e-commerce orders, food delivery, ride-hailing, ticket booking, payments and wallets, chat and presence, video pipelines, notifications, monolith migration, and critiquing a given architecture. Each card gives the calibration, the spine of the design, and the hard part
• The twelve red flags with their fixes

Download the Microservices Interview Cheat Sheet (PDF)

How to Practice

Reading a good answer feels like learning, but the interview asks you to produce one. Three drills, in order of value:

Talk, do not read. Take a question, set a 45-minute timer, and deliver the whole thing out loud to an empty room. The gap between what you know and what you can say under time is the entire problem, and it only closes by speaking.

Run the self-audit drill. Record yourself answering five rapid questions, then count how many answers included a cost or a failure mode without being asked. The target is five of five.

Collect your own follow-ups. After each practice run, write the three questions you would have asked yourself, and answer them next time. The follow-up conversation is where the grade is decided, and it is the part almost nobody rehearses.

Work through the common question families rather than memorizing individual answers. E-commerce orders, food delivery and ride-hailing, ticket booking, payments and wallets, chat and presence, video pipelines, notification systems, and monolith migration cover nearly everything you will be asked. Each family has its own hard part: transactional integrity, physical-world contention, a hard never-oversell invariant, auditability, stateful connections, long-running compute, fan-out, and organizational risk.

Where to Go Next

Everything in this article is the opening chapter of a longer method. Grokking Microservices for System Design Interviews walks the whole thing: the monolith-or-microservices decision, boundaries and data ownership, communication per edge, consistency without distributed transactions, the failure walk, and operations. It closes with the ten worked case studies above, each delivered end to end, plus a rapid-review module built for the final days before an interview.

If you want the mechanisms behind the patterns named here, sagas, the outbox, circuit breakers, bulkheads, service discovery, CQRS, and the rest, Grokking Microservices Design Patterns teaches them one at a time with worked examples. The two are designed as a pair: that course is the engine manual, this one is the driving test.

If you want the broader interview, Grokking the System Design Interview covers the full round, and Grokking System Design Fundamentals is the place to start if the vocabulary in this article was new.

The framework itself is the part worth memorizing. Requirements, boundaries, communication, consistency, failure, operations. Six steps, in dependency order, with the cost attached to every claim.