Microservices questions are really questions about failure

Microservices questions are really questions about failure
Drawing three boxes is easy. The round turns on what you say happens when one box stops answering, and whether you can admit that a monolith might be the better choice.

Written after a design round that fell apart on retries. Updated October 2026. 8 min read

Bad answer: the order fails because email failed.
Better: the order is placed, the email is queued and retried, and the user sees a success.
The short version: draw boundaries around data ownership rather than around nouns, prefer asynchronous messaging for anything that is not needed to answer the user right now, make retried operations idempotent, and be willing to say that a single service would be simpler here. That last one impresses more interviewers than it loses.

Terminology varies between teams. What matters is that you can defend the boundaries you draw.

The round that fell apart on one follow up
"What happens if the email service is down?"

I had drawn orders, payments and email, with arrows between them, and I felt good. Then the interviewer took the email service away. In my design the order request waited for it, so taking it away meant customers could not place orders because a receipt could not be sent.

Nobody is impressed by the boxes. They are listening for what happens when one of them stops answering.
Boundaries follow data, not nouns
The first question to answer out loud.

A service should own its data and be deployable on its own. If two services need to write the same table to do their jobs, the boundary is in the wrong place. If a single user action requires five synchronous hops, the boundary is also in the wrong place, just in a different way.

Synchronous or asynchronous
Decide per call, and say why.

Sometimes
Not the tool for this
Which style suits which kind of work.
The rule I use out loud: if the user cannot get an answer without it, call it synchronously. Everything else becomes an event, which is also what stops one failing dependency from taking down the main path.

Retries make idempotency mandatory
Say this before you are asked.

Once calls can be retried, every operation must be safe to receive twice. That usually means a key on the request that the receiver stores, so a duplicate returns the original result rather than creating a second payment. This is the single most common follow up in distributed design rounds.

The vocabulary worth having ready
Four terms, one sentence each.

Circuit breaker
Stop calling a failing dependency for a while so you fail fast rather than queueing.
Backoff with jitter
Space out retries and randomise them so clients do not retry in lockstep.
Saga
A workflow across services where each step has a compensating action.
Outbox
Write the event in the same transaction as the data so the two cannot disagree.
The answer that scores well
Being willing to say monolith.

Reasons to split
Different scaling profiles
Clear data ownership
Teams blocking each other on deploys
Different reliability requirements
Reasons to wait
A small team
An unclear domain
No deployment automation yet
Every change touching several services
How I practised the follow ups
Design, then remove a service.

My routine was to draw a design and then delete one box and talk through what happens. I used Phantom Code AI[https://www.phantomcodeai.com/] in its slower reasoning mode to attack the design rather than produce one, asking what breaks when a dependency times out or when a message is delivered twice. Since it covers coding, SQL and behavioral practice as well, one evening habit carried the whole loop.

Common questions
Short answers.

How do I pick boundaries?
When should calls be asynchronous?
What is a saga?
Is a monolith ever right?
Design for the day something is down
Every distributed design question eventually becomes a question about partial failure, because that is what the job actually is.

Take a design you have drawn and remove one service. Write what the user sees.

Written after an email service taught me a lesson

What is the smallest useful service you have shipped?

And did it stay that size?