Build a Delivery Payout Calculation API

# Build a Delivery Payout Calculation API Build a payment-service endpoint `POST /payout` that accepts a delivery worker ID, requests that worker's order-activity sequence for a specified day from an upstream dependency, calculates the payout, and returns the dollar amount. The base rate is `$0.30` per minute. During any interval, the rate is the number of ongoing deliveries multiplied by the base rate. For example, two simultaneous active deliveries earn twice the one-delivery rate during their overlap. For this practice version, the upstream activity contains an `orderId`, a `START` or `END` type, and a timestamp. Calculate from exact elapsed seconds, prorate the per-minute rate, and round the final daily total to cents once using the agreed monetary rounding rule. ### Constraints & Assumptions - Every valid order has one `START` followed by one `END` for the requested worker and day. - Activities may arrive unsorted; equal timestamps create no paid elapsed interval between them. - A malformed or incomplete activity sequence causes an explicit error and no guessed payout. - Money uses exact decimal or integer minor-unit arithmetic rather than binary floating point. - Upstream URL, authentication, timeout, response schema, day boundary, and response envelope are provided by the assessment. ### Clarifying Questions to Ask - Is pay prorated by second, rounded per order, rounded per interval, or rounded only on the final total? - Which timezone defines the workday, especially across daylight-saving transitions? - Can an order cross the requested day boundary, and how is the opening active state obtained? - What status should the payout endpoint return for upstream timeout, malformed activity, or an unknown worker? - May the activity response be cached, and what correction or freshness behavior invalidates it? ### What a Strong Answer Covers - Input validation and a bounded upstream client with status checks, explicit timeouts, and retry rules appropriate to a read dependency. - Validation and deterministic sorting of activities, including duplicate, missing, reversed, and cross-boundary events. - A sweep over time that accrues elapsed duration multiplied by the active-delivery count and exact base rate. - Active order IDs rather than only a counter so duplicate starts and unmatched ends are detected. - Exact money representation and one documented rounding boundary. - Clear API error mapping, observability, caching or correction semantics, and protection against partial upstream data. - Unit tests for payout math and contract tests for upstream and endpoint behavior. ### Follow-up Questions 1. How do you detect a duplicate `START` that would otherwise inflate the active-delivery count? 2. Two events share a timestamp. Why should their internal ordering not change accrued pay? 3. What changes if an order begins before midnight and ends during the requested day? 4. Which upstream failures are safe to retry, and how do you prevent a retry storm? 5. How would you prove that overlapping deliveries are counted without rounding each interval differently?