Compute Delivery Pay from an Event Stream and Peak Windows

A delivery worker's day is represented by events containing an order ID, worker ID, timestamp, and status such as accepted, fulfilled, or canceled. Pay accrues per active minute per concurrent order. Explain how you would compute total pay and extend the calculation so a peak-time window pays double, including intervals that cross a peak boundary. The event and payment rules need clarification before implementation. Do not silently choose cancellation, duplicate-event, or incomplete-order behavior. ### Constraints & Assumptions - Multiple orders may be active at once. - A peak interval, such as 17:00–19:00, changes the rate within an active period. - Clarify the base rate, timestamp units, input order, day boundary, and rounding policy. ### Clarifying Questions to Ask - Does each active order earn the full base rate, and does a canceled order retain pay earned before cancellation? - Can events be out of order or repeated, and what identifies a duplicate? - How should missing acceptance or terminal events be handled? ### Part 1 — Calculate Pay Describe the event processing and interval calculation for normal and peak periods. #### What This Part Should Cover - Active-order state, sorting, and simultaneous timestamps. - Explicit status transitions and handling of invalid events. - Splitting at peak boundaries and exact monetary arithmetic. ### Part 2 — Operate as a Live Service Explain how the batch calculation could become a service and how upstream API failures should be handled. #### What This Part Should Cover - Durable progress, event deduplication, and late-data correction. - Bounded retries with backoff and jitter, circuit breaking, and safe retry identities. - A distinction between provisional and finalized pay. ```hint Between adjacent event or rate-change boundaries, both active-order count and pay multiplier are constant. ``` ### What a Strong Answer Covers Give a complete calculation under stated rules, then explain which parts change if cancellation or late-event policy differs. Production recovery must preserve the same payment meaning rather than simply rerun side effects. ### Follow-up Questions - How would a late cancellation change an already displayed total? - When should rounding occur? - What if the upstream times out after accepting a request?