Build an Order-Exception Microservice with Explicit Refund Policies

Design a local microservice that handles reported delivery problems for orders, including partial loss, complete loss, and delay. It should decide whether the response is a refund or a partial refund and run well enough to demonstrate the expected behavior. ### Requirements and Constraints The task deliberately leaves business rules open. Define a minimal, explicit demonstration scope before implementation rather than assuming a refund formula or production policy. AI coding tools may help build the service, but you must explain the requirements, run it locally, and validate its behavior. This is an application-integration and policy-modeling exercise, not a single deterministic algorithm problem. ### Clarifying Questions - How are partial loss, complete loss, and delay represented, and can more than one apply to the same order? - Which order facts establish the amount eligible for a refund, and who supplies the policy? - Does the demonstration need only a recorded refund decision, or an integration with a payment sandbox? - How should the service handle repeated reports, missing evidence, and already-processed refunds? ```hint Separate facts from the policy decision An order being partially missing is a fact about the report. The amount to refund depends on a policy and authoritative order data that have to be defined separately. ``` ### What a Strong Answer Covers - A bounded API and data model for order facts, problem reports, decisions, and processing state. - Explicit rules for the three stated problem categories, with unresolved policy treated as an open requirement. - A distinction between full and partial refunds and safeguards against duplicate or excessive refund decisions. - A working local service with examples that exercise the agreed rules and error paths. - Effective use of an AI coding tool through specific requirements, review, and observed tests. - A truthful account of what the demonstration implements and what would be required for production use. ### Follow-up Questions 1. How would you handle a report that combines a late delivery with missing items? 2. What happens when two reports about the same order arrive at the same time? 3. How would you test the service when the refund policy changes while keeping the original decisions auditable?