Design Patterns (GoF and modern) Module 8
Resilience patterns as code interview questions
Interview questions on resilience patterns as code: short warm-ups, then what each harder question tests, the first step of a good answer and its follow-ups.
Warm-up questions
Short questions with short answers, each answered in full.
-
Fresher to mid
Which failures should a retry policy retry, and which should it never retry?
Answered in the lesson Retry with exponential backoff and jitter
-
Fresher to mid
Why does a circuit breaker need a minimum throughput as well as a failure ratio?
Answered in the lesson Circuit breaker: fail fast, recover safely
-
Fresher to mid
What is the difference between a timeout and a deadline, and why do services pass deadlines rather than timeouts?
A timeout is a duration for one wait: give this call 2 seconds. A deadline is a moment for the whole request: everything must be finished by a point in time that was set once, where the request entered. A service that receives a deadline works out how much time is left and passes that on, so every hop below stops when the user stops waiting. If each hop starts a fresh timeout instead, the times add up down the chain: the edge gives up at 300 ms while a service two hops down keeps working, holding a connection, for a request nobody will read. Between machines the deadline usually travels as the time remaining, as gRPC sends it, because the clocks of two servers may disagree.
From the lesson Timeouts, deadlines and cancellation
-
Fresher to mid
What makes an idempotency key work, and who should create it?
The client creates the key, once per logical operation, before the first attempt, and sends the same key with every retry; a key made inside the retry loop is new each time and protects nothing. The server stores the key with a fingerprint of the request and the response it gave, in the same transaction as the work, so a repeat finds the key and gets the stored response instead of a second charge. A repeat that arrives while the first is still running gets 409, and a key reused for a different request gets 422. Use a random, unique value such as a UUID, scope it to the caller, and keep it at least as long as clients may retry.
From the lesson Idempotency keys, outbox and saga in code
Questions with model answers
What each question tests, the first step of a good answer and the follow-ups to expect.
-
Mid to senior
A mobile app, an API gateway and an orders service each retry a failing call three times. During an outage of the payments service below them, payments receives 27 times its normal load and cannot recover. How do you change the retries, and how do you show that the change works?
- What it tests
- Retry amplification across layers, choosing one retry point, retry budgets, and proving call counts with fakes instead of production traffic.
- First step
- Multiply the attempts per layer: 3 × 3 × 3 = 27 calls at the bottom for one user action. Then pick the single layer best placed to retry, usually the one next to the failing dependency, and decide what the other layers do with the error it returns.
- Follow-ups
-
- The mobile app is already on users' phones and cannot change quickly.
- How large should the retry budget be?
- How do the upper layers know not to retry?
From the lesson Retry with exponential backoff and jitter
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
A partner's API answers your checkout service with 429 Too Many Requests and Retry-After: 3600. Your retry policy obeys the header, and checkout requests hang until users give up. What should the policy have done, and what would you change around it?
- What it tests
- Treating Retry-After as a lower bound inside a deadline, failing fast, and designing what checkout does while a dependency limits its rate.
- First step
- Compare the wait the server asked for with the time the caller has left: an hour against a checkout deadline of a few seconds. A policy never waits past the caller's deadline, so it should fail at once and let the caller choose what to show or queue.
- Follow-ups
-
- Should the client remember the Retry-After for the next requests?
- The Retry-After is an HTTP date and the client's clock is wrong.
- How would you test this without waiting an hour?
From the lesson Retry with exponential backoff and jitter
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
A circuit breaker uses a failure ratio of 10 % over a 30-second window with a minimum of 100 calls. One night its dependency, called twice a second, was down for 20 minutes, and the breaker never opened. Explain why, and choose settings that would have opened it without making it trip on noise during the day.
- What it tests
- How the minimum throughput, the window length and the call rate interact, and choosing breaker settings from traffic numbers.
- First step
- Work out how many calls the window can hold at night: 2 calls a second × 30 seconds = 60, which is below the minimum of 100, so the ratio is never judged. Then find the daytime call rate and pick a window and minimum that work at both rates.
- Follow-ups
-
- Why not set the minimum throughput to 1?
- The day-time rate is 200 calls a second. Does one setting fit both?
- How would you have noticed this before the outage?
From the lesson Circuit breaker: fail fast, recover safely
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
-
Mid to senior
Your HTTP client has a retry policy with three attempts and a circuit breaker. In which order do you put them, and what should the retry policy do when the breaker refuses a call? Support the choice with what each order does during an outage.
- What it tests
- Composing policies as decorators, what each order counts, and treating a breaker's refusal as a non-transient error.
- First step
- Write both stacks from the outside in and follow one request through an outage. With the retry outside, the breaker sees every attempt; with the breaker outside, it sees one outcome per request after all attempts failed. Then ask what a retry gains by retrying a refusal.
- Follow-ups
-
- Where does the timeout for each attempt go?
- The breaker reports when its next trial is due. Should the retry wait for it?
- How do you test that the order in production is the one you chose?
From the lesson Circuit breaker: fail fast, recover safely
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
-
Senior to staff
When a breaker's break ends, 200 queued requests reach a database that is still recovering, it fails again and the breaker opens for another full break. This repeats several times. What is happening, and what do you change in the breaker and around it?
- What it tests
- Half-open trial limits, how a recovering dependency fails under a burst, timeouts on trial calls, and smoothing the return of traffic.
- First step
- Count what the half-open state lets through: if every waiting caller goes at once, the trial is really a burst of 200. Limit the trial calls to what the recovering database can serve, and refuse the rest until a trial decides.
- Follow-ups
-
- How many trial calls would you allow?
- A trial call hangs and never returns. What happens?
- Where should the 200 queued requests go instead?
From the lesson Circuit breaker: fail fast, recover safely
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
-
Mid to senior
A request crosses four services, each with a 2-second timeout on its call to the next. Users see errors after 2 seconds, but the database shows queries still running 6 seconds later, and its connections run out during slow spells. Explain what is happening and how you would fix it.
- What it tests
- Timeouts that restart at every hop, deadline propagation, cancellation that reaches the database, and how a slow spell turns into exhausted connections.
- First step
- Draw the chain and mark when each timer starts: every hop starts a fresh 2 seconds when it calls the next, so the bottom can run long after the top gave up. Then check whether the database query is ever cancelled when its caller stops waiting.
- Follow-ups
-
- How is the deadline sent from one service to the next?
- One service in the chain cannot be changed.
- How do you test the fix?
From the lesson Timeouts, deadlines and cancellation
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Senior to staff
A checkout request has a 5-second deadline. At 4.9 seconds the payment call is still in flight when the deadline passes and the request is cancelled. Should cancellation stop the payment call? Explain how you keep the order, the charge and what the user sees consistent.
- What it tests
- Knowing which work must not be cancelled half-way, protecting a step from cancellation, idempotency keys and reconciling an outcome that is unknown.
- First step
- Separate the user's wait from the payment's outcome: the user can stop waiting at the deadline, but a charge that may already have been made must still reach a known state. Find the step after which the work must finish, and protect it.
- Follow-ups
-
- How do you protect one step from cancellation in asyncio?
- The provider's answer arrives after the deadline.
- What does the user see?
From the lesson Timeouts, deadlines and cancellation
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
-
Mid to senior
After a dependency was slow for ten minutes, a service's connection pool stays empty and every request fails, although the dependency is fast again. The timeouts fired as designed. What probably leaked, how do you confirm it, and how do you make the leak impossible?
- What it tests
- Resources held across a cancellation point, finding a leak with pool numbers, and try/finally or context managers as the structural fix.
- First step
- Compare the connections the pool counts as in use with the queries actually running on the dependency. Connections in use with no query behind them were taken by calls that were cancelled before they gave them back.
- Follow-ups
-
- How would you find the code path that leaks?
- Can the pool protect itself against such leaks?
- How do you test the fix?
From the lesson Timeouts, deadlines and cancellation
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
-
Mid to senior
Customers report being charged twice for one top-up. The server looks the idempotency key up, charges the payment provider, then saves the key with the result. Logs show two requests with the same key 40 ms apart. Explain the bug, fix it, and say what happens if the server crashes right after charging.
- What it tests
- The check-then-act race on idempotency keys, claiming a key atomically before external work, in-progress states, 409 responses and repairing operations stuck in progress.
- First step
- Lay the two requests side by side: both look the key up before either saves it, so both find nothing and both charge. The fix must make the key's first use a single atomic step that only one request can win, before any money moves.
- Follow-ups
-
- What does the second request get back?
- How do you repair a key stuck in progress?
- Where else must the key be sent?
From the lesson Idempotency keys, outbox and saga in code
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
Your order service commits an order and then publishes an OrderPlaced event to a broker. About 1 order in 2,000 is never shipped, and the warehouse never received its event. Explain the cause and design a fix, with the costs it brings.
- What it tests
- Dual writes and the window between them, the transactional outbox and its relay, at-least-once delivery and idempotent consumers.
- First step
- Find the moment where the two writes can part: after the order commits and before the publish succeeds. Any crash, deploy or broker error in that window leaves an order without its event, and nothing ever retries the publish.
- Follow-ups
-
- Why not publish first and then commit the order?
- What does the warehouse have to change?
- How large does the outbox grow, and who cleans it?
From the lesson Idempotency keys, outbox and saga in code
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
-
Senior to staff
A checkout saga reserves stock, charges the card and hands the parcel to a courier. The courier step fails after the card was charged. How do you design the compensations, and what do you do about steps that cannot be undone, such as a confirmation email already sent?
- What it tests
- Compensations as business actions, reverse order, the pivot step after which a saga must finish, retryable steps and idempotent compensations.
- First step
- List each step with its compensation and whether it can be undone at all: release the stock, refund the charge, and nothing for an email. Then decide whether the courier failure should be compensated or retried, because retrying forward is often cheaper than undoing.
- Follow-ups
-
- Where does the pivot step go in this saga?
- The refund fails too. What now?
- How do you know the saga is stuck?
From the lesson Idempotency keys, outbox and saga in code
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 2 minutes
All Design Patterns (GoF and modern) interview questions · The Design Patterns (GoF and modern) track