Design delivery driver payment system

Q: Design delivery driver payment system

A Rippling software-engineer system-design screen: build an in-memory, object-oriented driver-payroll service with add_driver, record_delivery, get_total_cost, pay_up_to, and get_total_cost_unpaid. It tests time-interval accounting, integer-cents money math, idempotent partial-vs-whole payout state, double-pay prevention for overlapping work, and a clean path from prototype to a transactional, indexed production design.

Q: How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

Q: What difficulty level is this interview question?

This is a medium difficulty System Design question, commonly asked during Technical Screen rounds at Rippling.

Q: What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Rippling during technical interviews.

Question

Design a delivery-driver payment system

Design and implement an in-memory, object-oriented service that tracks delivery-driver work and computes payroll. The interview expects a clean OO implementation plus a discussion of how each design decision would change in production.

Method names vary by interviewer, but the semantics below are fixed.

Operations to support:

add_driver(driver_id, usd_hourly_rate) — register a driver with an hourly rate.
record_delivery(driver_id, start_time, end_time) — log a completed delivery work interval for a driver.
get_total_cost() — return the total accrued labor cost across all drivers and all recorded deliveries, independent of what has been paid .
pay_up_to(pay_time) — settle / mark wages as paid for all work performed up to the given timestamp. Calling it repeatedly with the same (or an earlier) time must not double-pay .
get_total_cost_unpaid() — return the total unsettled wages remaining after payouts.

Provide a clean object-oriented implementation, and call out any simplifications you make for the interview versus what a production system would require.

Constraints & Assumptions

State these explicitly at the top of your design so the cost math is unambiguous:

Times have at least 1-second precision .
A single delivery is at most ~3 hours long.
A delivery is recorded only after it has completed ( end_time is in the past).
Hourly rates are quoted in USD ; payroll totals must be exact (no accumulated rounding error).
Anything left undefined by the prompt — timezone, interval endpoint inclusivity, whether a driver can have overlapping deliveries, whether pay_up_to settles whole deliveries or partial slices, what happens when a rate changes — is yours to decide and justify. Surface those decisions as explicit assumptions rather than guessing silently.

Clarifying Questions to Ask

Scope the problem with the interviewer before implementing:

Does pay_up_to(T) settle a whole delivery only once its end_time ≤ T , or does it settle a partial slice (up to min(end_time, T) ) of a delivery that straddles T ?
Can a single driver have overlapping deliveries, or is it strictly one delivery at a time? If overlaps are allowed, should shared time be paid once or per-interval?
What timezone / unit are timestamps in, and are intervals half-open, closed, or open at the endpoints?
Can deliveries be back-dated, edited, or cancelled after a payout has already run — and if so, must history stay auditable?
What rate applies if a driver's hourly rate changes — the rate at the time of the delivery, or the current rate?
What read/write volume should this support, and is a real-money disbursement (bank transfer) attached to pay_up_to , or is it just bookkeeping?

What a Strong Answer Covers

A strong answer nails the time-and-money model first, then layers a payout state machine on top, and finally shows it generalizes to a relational, concurrent, auditable service. Across the whole design the interviewer is looking for:

Data models & persistence — clean OO entities (driver, delivery interval, payout state) for the interview, mapped to relational tables for production; whether read totals are maintained as incremental aggregates or recomputed.
Time handling — units, timezone, endpoint inclusivity (and why that choice makes back-to-back intervals not overlap), plus validation of start < end and the ~3-hour bound.
Money handling — avoiding floating-point error (integer cents), a single explicit cost formula, and a rounding strategy applied at exactly one boundary.
Payout semantics — a clear choice between whole-delivery mark-paid and partial-slice settlement, and a concrete argument for why repeated/out-of-order pay_up_to is idempotent and monotone .
The rounding-drift trap — recognizing that summing independently-rounded partial slices can make a fully-paid delivery leave a nonzero (even negative) residual, and settling off an anchored cumulative instead.
Overlapping & back-to-back intervals — an explicit reject-vs-merge policy for double-pay avoidance, and the observation that adjacent intervals ( end == next.start ) are not overlaps.
Late / back-dated deliveries, edits, cancellations — why a back-dated entry needs no retroactive fix-up under the right framing, and how edits/cancellations preserve aggregate consistency and an audit trail.
Performance — target time/space complexity per operation, and which indexes or O(1) aggregates make the reads cheap and the overlap/payout scans avoid full table scans.

Follow-up Questions

Be ready for the interviewer to push deeper after your main answer:

A driver's hourly rate changes mid-history. Should past deliveries reprice, or freeze the rate at record time — and how does your data model enforce that?
pay_up_to triggers a real bank transfer and the HTTP call is retried after a network blip. How do you guarantee the driver isn't disbursed twice, given the state may already have advanced?
At 100× write volume with concurrent payouts, what breaks first, and how do you settle in batches without deadlocks or torn reads of the aggregates?
How would you re-shape this around an immutable event log ( DELIVERY_RECORDED , PAYOUT , ADJUSTMENT , …) so the mutable fields become a projection you can rebuild and audit?

Design delivery driver payment system

Quick Overview

Design delivery driver payment system

Design a delivery-driver payment system

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Submit Your Answer to Earn 20XP

Design delivery driver payment system

Quick Overview

Design delivery driver payment system

Design a delivery-driver payment system

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Submit Your Answer to Earn 20XP