MicroservicesSenior

Retry a slow dependency without taking yourself down

Order Service calls Inventory Service. Inventory has slowed from 40ms to 3 seconds. Order Service now times out, retries three times, and its own thread pool is exhausted — so Order Service is down too, and the retries are keeping Inventory down.

Make Order Service survive a slow Inventory. There is no answer here that is only code: say what the endpoint returns when Inventory is unavailable, and defend it.

Example

inputInventory p99 = 3s, 200 rpsoutputOrder Service stays up

Some requests fail fast. That is the point — a fast failure is a result, a hung thread is not.

Constraints

  • Total time spent on one downstream call must be bounded, retries included.
  • Retries must not multiply load on a dependency that is already struggling.
  • The policy the tests hold you to: at most 2 attempts per call, a 200ms timeout per attempt, and the breaker opens after 3 consecutive failed calls and then fails immediately without calling Inventory. Those numbers are stated because "make it resilient" has infinitely many correct answers and no testable one.

Hints

Hint 1
A timeout without a retry budget is three timeouts.
Hint 2
A circuit breaker is what stops the retries when the dependency is already down.
Hint 3
Retrying immediately is what turns one slow service into two down services — jitter the backoff.
Hint 4
Bulkheads: the pool that calls Inventory should not be the pool that serves your own traffic.

Stuck? The lesson behind this problem: 🧩 Circuit breakers and bulkheads

Your retry budget is spent and the breaker is open. What does POST /api/orders return, and why that?

Pick one first — the answer stays hidden until you do.
java
Tab indents · Escape first to tab out

Test cases

These are the specification. Run tests checks your answer against them.

CaseInputExpected
inventory healthyp99 = 40msorder placed
inventory slowp99 = 3sfails within the budget, pool not exhausted
inventory downconnection refusedbreaker opens, no retry storm