##### Question Design an object-oriented, in-memory **Delivery Cost System** for a food-delivery company. Drivers register with an hourly rate, deliveries are recorded as they complete, and the system reports cost and payment metrics for a live dashboard. Implement the following: 1. **`registerDriver(driverId, hourlyRate)`** — Add or update (upsert) a driver and their hourly rate. Drivers may have different rates. Decide whether a rate change should affect already-recorded deliveries. 2. **`recordDelivery(driverId, startTime, endTime)`** — Record one completed delivery. Cost accrues as `hourlyRate(driverId) x duration`. Deliveries are recorded immediately after completion and last no more than 3 hours. A single driver may have overlapping deliveries, and each is paid independently. Define interval semantics (inclusive/exclusive endpoints), how partial hours are prorated, and the time representation (require at least one-second precision). 3. **`getTotalCost()`** — Return the aggregated cost of all recorded deliveries across all drivers. This drives a live dashboard, so it should be cheap to call. 4. **`payUpTo(timestamp)`** — Mark all accrued cost up to the given timestamp as paid. A delivery that straddles the timestamp should have only the portion up to the timestamp counted as paid. Repeated or earlier calls must be idempotent. 5. **`getTotalUnpaid()`** — Return the remaining unpaid amount. 6. **`maxSimultaneousDriversInPast24Hours()`** — Return the maximum number of drivers that were simultaneously on a delivery at any instant within the last 24 hours. Discuss your class design, core data structures, method signatures, numeric precision (avoiding floating-point money errors), rounding, time-zone handling, thread-safety for a concurrent dashboard, idempotency, and the time/space complexity of each operation.

A Rippling software-engineer system-design screen: build an object-oriented, in-memory delivery cost system that registers drivers with hourly rates, records deliveries, and reports total cost, paid/unpaid amounts via an idempotent payUpTo cutoff, and the max number of drivers simultaneously delivering in the last 24 hours. It tests time-interval modeling, exact monetary arithmetic, sweep-line concurrency, idempotency, time-zone handling, and thread-safe dashboard reads.

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.

What difficulty level is this interview question?

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

What role is this question designed for?

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

Design a delivery cost system | Rippling Interview Question

Design an object-oriented, in-memory Delivery Cost System for a food-delivery company.

Drivers register with an hourly rate, completed deliveries are recorded as they finish, and the system reports cost and payment metrics for a live dashboard. Implement the API below, then walk through your design decisions.

Context & assumptions

Everything lives in memory — no database is required for the core design (though you may discuss persistence as an extension).
Drivers may have different hourly rates , and a rate can be updated over time.
A single driver may run overlapping deliveries , and each delivery is paid independently.
Each delivery lasts no more than 3 hours and is recorded immediately after it completes.
Time must support at least one-second precision .

API to implement

registerDriver(driverId, hourlyRate) — Add or update (upsert) a driver and their hourly rate. Decide whether changing a rate should affect already-recorded deliveries , and justify your choice.
recordDelivery(driverId, startTime, endTime) — Record one completed delivery. Cost accrues as hourlyRate(driverId) × duration . When defining this method, specify:
- Interval semantics — are endpoints inclusive or exclusive (e.g. [start, end) )?
- Proration — how partial hours are handled.
- Time representation — the type/units used to store an instant (one-second precision or finer).
getTotalCost() — Return the aggregated cost of all recorded deliveries across all drivers. This powers a live dashboard, so it should be cheap to call .
payUpTo(timestamp) — Mark all accrued cost up to timestamp as paid. A delivery that straddles the timestamp counts only the portion up to the timestamp as paid. Repeated calls, or calls with an earlier timestamp, must be idempotent .
getTotalUnpaid() — Return the remaining unpaid amount.
maxSimultaneousDriversInPast24Hours() — Return the maximum number of distinct drivers simultaneously on a delivery at any instant within the last 24 hours.

What to discuss

Cover the following as part of your design:

Class design & core data structures , and the method signatures you'd expose.
Numeric precision — how you avoid floating-point money errors, plus rounding policy.
Time-zone handling .
Thread-safety for a concurrent dashboard (simultaneous reads and writes).
Idempotency of payUpTo .
The time and space complexity of each operation.

Design an object-oriented, in-memory Delivery Cost System for a food-delivery company.

Context & assumptions

Everything lives in memory — no database is required for the core design (though you may discuss persistence as an extension).
Drivers may have different hourly rates , and a rate can be updated over time.
A single driver may run overlapping deliveries , and each delivery is paid independently.
Each delivery lasts no more than 3 hours and is recorded immediately after it completes.
Time must support at least one-second precision .

API to implement

registerDriver(driverId, hourlyRate) — Add or update (upsert) a driver and their hourly rate. Decide whether changing a rate should affect already-recorded deliveries , and justify your choice.
recordDelivery(driverId, startTime, endTime) — Record one completed delivery. Cost accrues as hourlyRate(driverId) × duration . When defining this method, specify:
- Interval semantics — are endpoints inclusive or exclusive (e.g. [start, end) )?
- Proration — how partial hours are handled.
- Time representation — the type/units used to store an instant (one-second precision or finer).
getTotalCost() — Return the aggregated cost of all recorded deliveries across all drivers. This powers a live dashboard, so it should be cheap to call .
payUpTo(timestamp) — Mark all accrued cost up to timestamp as paid. A delivery that straddles the timestamp counts only the portion up to the timestamp as paid. Repeated calls, or calls with an earlier timestamp, must be idempotent .
getTotalUnpaid() — Return the remaining unpaid amount.
maxSimultaneousDriversInPast24Hours() — Return the maximum number of distinct drivers simultaneously on a delivery at any instant within the last 24 hours.

What to discuss

Cover the following as part of your design:

Class design & core data structures , and the method signatures you'd expose.
Numeric precision — how you avoid floating-point money errors, plus rounding policy.
Time-zone handling .
Thread-safety for a concurrent dashboard (simultaneous reads and writes).
Idempotency of payUpTo .
The time and space complexity of each operation.

Design a delivery cost system

Quick Overview

Context & assumptions

API to implement

What to discuss

Solution

Submit Your Answer

Design a delivery cost system

Quick Overview

Context & assumptions

API to implement

What to discuss

Solution

Submit Your Answer