Food Delivery Cost & Driver Payout Calculation

Problem: Food Delivery — Cost Calculation & Driver Payout You need to implement a set of computations for a food delivery platform, consisting of three parts. The system includes: Delivery (Order): one trip from a restaurant to a customer. Driver: fulfills deliveries. Pricing rules: used to compute a delivery cost. Timestamp: used to settle driver payouts at a given time. Complete the following Part 1/2/3. Part 1: Compute the delivery cost for a single order Implement a function to compute an order’s cost from order attributes and pricing rules. Requirements: cost must be derived solely from the input order and rules (no hidden global state). Must be able to cover: base fee + distance/time components + optional surcharges (e.g., surge/tips/minimum fee). Input (suggested abstraction): created_at distance_km duration_min Optional: order_subtotal, tip Pricing rules (e.g., base_fee, per_km_fee, per_min_fee, min_fee, surge_multiplier, etc.) Output: The order cost (numeric) Part 2: Given a timestamp, compute total payout owed to drivers Orders are continuously created and assigned to drivers. Given a timestamp t, compute how much money in total should be paid to drivers as of time t (or within a settlement window). Requirements: Clearly define your settlement semantics, e.g.: include all orders with completed_at <= t; or include only orders not yet paid and completed_at <= t; or include orders in a window (t - window, t]. Per-order driver earnings may be a share of cost (e.g., driver_share) or computed by separate rules—your abstraction is flexible but must be explicit and consistent. Input (suggested abstraction): A list/stream of order records containing driver_id, completed_at, and either cost or enough data to compute it (Part 1) Query timestamp t Driver payout rule (e.g., driver_share) Output: Total amount owed to drivers at time t Part 3: Open-ended extension (design/engineering) Based on Part 1/2, discuss or implement an extensible approach to support one or more: Incremental settlement (avoid scanning all historical orders per query) Handling refunds/cancellations and their impact on payouts City/driver-tier specific pricing and revenue share Idempotent settlement (avoid double-paying across repeated queries) High write throughput (order ingestion) with frequent time-based payout queries Explain your data structures/storage design, complexity, and correctness. Constraints (for interview discussion) Up to 10^6 orders Up to 10^5 queries Timestamps are comparable (e.g., integer seconds) Use integer cents to avoid floating-point errors Example (illustrative) Assume: cost = base_fee + per_km_fee * distance_km earning = cost * driver_share Given: distance=3km, base=200 cents, per_km=50 cents, driver_share=0.8 cost = 200 + 50*3 = 350 earning = 350*0.8 = 280 At query time t, sum earnings over all orders with completed_at <= t. Example Input # orders: # o1 completed_at=100 distance=3 # o2 completed_at=120 distance=5 # pricing: base=200 per_km=50 share=4/5 # query t=110 Output 280