Design a Delivery Driver Payment System
You are tasked with designing an in-memory payroll service responsible for calculating and paying delivery drivers based on their recorded work time. The system must ensure accurate cost accruals, facilitate partial payments up to a specified boundary time, and crucially, prevent double-paying for overlapping work intervals.
Assumptions
- Time values are represented as Unix timestamps in seconds. Intervals adhere to half-open semantics:
[start_time, end_time). - Each driver is assigned a constant USD hourly rate upon creation via
Add_driver. Changes to a driver's hourly rate are considered out of scope for the initial design but can be discussed as an extension. - The
Record_deliveryAPI only accepts completed deliveries, meaningend_timemust be strictly greater thanstart_time. Delivery records may be inserted out of chronological order. - For any given driver, overlapping or adjacent delivery intervals must be merged to ensure the driver is not compensated multiple times for the same minute of work.
- All monetary values should be tracked in integer cents to mitigate floating-point precision errors.
APIs to Support
Add_driver(driver_id, usd_hourly_rate): Registers a new driver with their specified hourly rate.Record_delivery(driver_id, start_time, end_time): Records a completed delivery for a driver.Get_Total_Cost(): Returns the total accumulated cost for all recorded work across all drivers.Pay_Up_To(pay_time): Processes payment for all unpaid work intervals up to, but not including,pay_time. This operation should mark the paid intervals as such.Total_Cost_Unpaid(): Returns the total cost of all work that has been recorded but not yet paid.
Design Considerations
Your explanation should cover:
- The data structures chosen to store drivers, their delivery intervals, rates, and payment statuses.
- The state-mutation logic for each API, specifically detailing how overlapping intervals are handled and how partial payments are managed.
- An object-oriented design approach that supports accurate and efficient payroll computation, including a discussion of complexity trade-offs.
AI interview prep
Core dilemma
Efficiently managing, merging, and splitting time intervals for individual drivers, especially with out-of-order insertions and partial payments, to ensure accurate cost accrual and prevent double-counting, all within an in-memory constraint.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design a Delivery Driver Payment System
You are tasked with designing an in-memory payroll service responsible for calculating and paying delivery drivers based on their recorded work time. The system must ensure accurate cost accruals, facilitate partial payments up to a specified boundary time, and crucially, prevent double-paying for overlapping work intervals.
Assumptions
- Time values are represented as Unix timestamps in seconds. Intervals adhere to half-open semantics:
[start_time, end_time). - Each driver is assigned a constant USD hourly rate upon creation via
Add_driver. Changes to a driver's hourly rate are considered out of scope for the initial design but can be discussed as an extension. - The
Record_deliveryAPI only accepts completed deliveries, meaningend_timemust be strictly greater thanstart_time. Delivery records may be inserted out of chronological order. - For any given driver, overlapping or adjacent delivery intervals must be merged to ensure the driver is not compensated multiple times for the same minute of work.
- All monetary values should be tracked in integer cents to mitigate floating-point precision errors.
APIs to Support
Add_driver(driver_id, usd_hourly_rate): Registers a new driver with their specified hourly rate.Record_delivery(driver_id, start_time, end_time): Records a completed delivery for a driver.Get_Total_Cost(): Returns the total accumulated cost for all recorded work across all drivers.Pay_Up_To(pay_time): Processes payment for all unpaid work intervals up to, but not including,pay_time. This operation should mark the paid intervals as such.Total_Cost_Unpaid(): Returns the total cost of all work that has been recorded but not yet paid.
Design Considerations
Your explanation should cover:
- The data structures chosen to store drivers, their delivery intervals, rates, and payment statuses.
- The state-mutation logic for each API, specifically detailing how overlapping intervals are handled and how partial payments are managed.
- An object-oriented design approach that supports accurate and efficient payroll computation, including a discussion of complexity trade-offs.