Katkat
Back

Build an Order-Exception Microservice with Explicit Refund Policies

DoorDashSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSoftware Engineering Fundamentals

Last updated

Design and demonstrate a local service for missing or delayed orders, with explicit refund rules, duplicate handling, and auditable decisions.

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?

Hints

Hint 1

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.

Follow-up questions

  • How would you handle a report that combines a late delivery with missing items?
  • What happens when two reports about the same order arrive at the same time?
  • How would you test the service when the refund policy changes while keeping the original decisions auditable?