Design Historical Driver Rates and Constant-Time Delivery Cost Totals

Design a Python model for a food-delivery company using Unix timestamps and dictionaries for driver rates and delivery records. Support rate updates with effective timestamps, queries for historical rates, delivery-cost calculation, and getTotalCost(). Explain how to make getTotalCost() O(1), and how to avoid monetary errors from binary floating-point arithmetic. ### Clarifying Questions The rate unit and billing policy are not specified. Does a delivery use the rate at its start, or split its duration at rate-change boundaries? Can updates be backdated, do historical deliveries get repriced, and when is rounding applied? How are duplicate records or corrections identified? Resolve these before committing to an API. For the worked design, choose hourly rates, half-open delivery intervals, piecewise billing across effective-rate boundaries, stable delivery IDs, and explicit adjustment entries for any retrospective correction. These are practice choices, not reported billing rules. ### Part 1 — Effective and Historical Rates Define storage and lookup for a driver's rate timeline, including a query exactly at an update timestamp and a time before the first known rate. #### What This Part Should Cover Specify boundary ownership, duplicate timestamp policy, and the cost of sorted-history insertion and lookup. ### Part 2 — Delivery Charges and Money Compute a charge under the chosen policy and explain why float followed by rounding to two decimals is insufficient. #### What This Part Should Cover Make units and the rounding boundary explicit, handle multiple rates within a delivery, and distinguish exact arithmetic from accounting policy. ### Part 3 — Constant-Time Total Maintain getTotalCost() in O(1) while preserving correctness under retries, corrections, and new rate information. Describe the tests you would write. #### What This Part Should Cover Move work to validated mutations, keep a clear total invariant, and do not hide the cost of retroactive repricing inside the getter. ### What a Strong Answer Covers A coherent model with historical lookup, explicit billing choices, exact monetary representation, transactional total updates, and targeted boundary and retry tests. ### Follow-up Questions - What would change if the entire delivery used only its start-time rate? - How would concurrent record ingestion protect the cached total? - What costs remain nonconstant even after getTotalCost() becomes O(1)?