Design a delivery cost system
Company: Rippling
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Technical Screen
##### Question
Design an object-oriented, in-memory **delivery cost dashboard** for a food-delivery company. Drivers register with an hourly rate, completed deliveries are recorded as they finish, and the service reports cost and payment metrics for a live dashboard.
Implement a class (or a small set of classes) supporting:
1. **`addDriver(driverId, usdHourlyRate)`** — register a driver and their hourly rate. Drivers have individual rates. State whether a repeat call rejects (the driver must not already exist) or upserts, and if it upserts, decide whether a rate change should affect already-recorded deliveries.
2. **`recordDelivery(driverId, startTime, endTime)`** — record one completed delivery for an existing driver. Cost accrues as `durationInHours × driverRate` — e.g. $10.00/hr for 1h30m pays $15.00. Deliveries are entered immediately after completion and never exceed 3 hours. A single driver may run multiple overlapping deliveries, and each is paid independently. Define interval semantics (inclusive/exclusive endpoints), how partial hours prorate, and the time representation (at least one-second precision).
3. **`getTotalCost()`** — the aggregated cost of all recorded deliveries across all drivers. This backs a live dashboard, so it should be cheap to call (exact display formatting is not required).
4. **`payUpTo(payTime)`** — mark accrued cost as paid up to the given timestamp (Unix epoch seconds). Say which semantics you are implementing: **(a) prorated** — a delivery straddling `payTime` has only the portion up to `payTime` counted as paid, or **(b) whole-delivery** — only deliveries that ended at or before `payTime` are marked paid. Repeated or earlier calls must be idempotent.
5. **`getTotalUnpaid()`** — the remaining unpaid amount.
6. **`maxSimultaneousDriversInPast24Hours()`** — the maximum number of drivers that were simultaneously on a delivery at any instant within the last 24 hours.
Before writing code, discuss and justify how you will store and represent time (Unix epoch seconds vs ISO-8601 strings, time-zone handling) and state your assumptions. Then cover your class design, core data structures, method signatures, numeric precision (avoiding floating-point money errors), rounding policy, idempotency, thread-safety for a concurrent dashboard, the time and space complexity of each operation, and what you would do differently in a production system.
Overview: A Rippling software-engineer system-design screen: build an object-oriented, in-memory delivery cost dashboard that registers drivers with hourly rates, records completed deliveries, and reports total cost, paid and unpaid amounts via an idempotent payUpTo cutoff, and the maximum number of drivers simultaneously delivering in the last 24 hours. It tests time-interval modeling, exact monetary arithmetic without floating-point drift, sweep-line concurrency counting, idempotency, time-zone handling, and thread-safe O(1) dashboard reads. The walkthrough covers both prorated and whole-delivery payment semantics, a full Python reference implementation, and the production hardening a real payroll service would need.