PracHub
QuestionsLearningGuidesInterview Prep
|Home/System Design/Rippling

Design a delivery cost dashboard with payments

Last updated: Jun 27, 2026

Quick Overview

Design a delivery cost dashboard with payments evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

  • medium
  • Rippling
  • System Design
  • Software Engineer

Design a delivery cost dashboard with payments

Company: Rippling

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Technical Screen

Design an object-oriented delivery cost dashboard service. Implement a class (or set of classes) that supports: 1) add_driver(driver_id: integer, usd_hourly_rate: float) — add a driver who is not yet in the system. 2) record_delivery(driver_id: integer, start_time, end_time) — record a completed delivery for an existing driver; deliveries are entered immediately after completion, no delivery exceeds 3 hours, and time precision must be at least one second. Drivers have individual hourly rates and can run multiple overlapping deliveries; each delivery is paid independently as duration_in_hours × driver_rate (e.g., $10.00/hr for 1h30m pays $15. 00). 3) get_total_cost() — return the aggregated cost of all recorded deliveries across all drivers (suitable for a live dashboard; exact formatting not required). Before coding, discuss and justify how you will store and represent time (e.g., Unix seconds, ISO-8601 strings, timezone handling) and any assumptions. Share design decisions, what you would do differently in production, and demonstrate good OOP practices. Extend the system with payment tracking: 4) pay_up_to(pay_time: integer, Unix time from epoch) — mark as paid all deliveries that ended at or before pay_time. 5) get_total_cost_unpaid() — return the total cost of all recorded deliveries that have not yet been paid. Inputs are valid; concurrency and thread-safety are out of scope.

Quick Answer: Design a delivery cost dashboard with payments evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Related Interview Questions

  • Design a Hotel Search and Reservation System - Rippling (medium)
  • Design a News Aggregation Service - Rippling (medium)
  • Design a News Aggregation System (Google News-style) - Rippling (medium)
  • Design a User Behavior Tracking (Clickstream Analytics) System - Rippling (medium)
  • Prevent Duplicate Payments Under High Load - Rippling (medium)
|Home/System Design/Rippling

Design a delivery cost dashboard with payments

Rippling logo
Rippling
Aug 1, 2025, 12:00 AM
mediumSoftware EngineerTechnical ScreenSystem Design
32
0

Design a delivery cost dashboard with payments

Object-Oriented Delivery Cost Dashboard Service

Goal

Design and implement an object-oriented service to track delivery costs across multiple drivers, support live dashboard totals, and track payment status.

API Requirements

Implement a class (or set of classes) that supports:

  1. add_driver(driver_id: integer, usd_hourly_rate: float)
    • Add a driver who is not yet in the system.
  2. record_delivery(driver_id: integer, start_time, end_time)
    • Record a completed delivery for an existing driver.
    • Deliveries are entered immediately after completion.
    • No delivery exceeds 3 hours.
    • Time precision must be at least one second.
    • Drivers have individual hourly rates and can run multiple overlapping deliveries; each delivery is paid independently as duration_in_hours × driver_rate.
    • Example: 10.00/hr×1h30m=10.00/hr × 1h30m = 10.00/hr×1h30m= 15.00.
  3. get_total_cost()
    • Return the aggregated cost of all recorded deliveries across all drivers (suitable for a live dashboard; exact formatting not required).
  4. pay_up_to(pay_time: integer, Unix time seconds from epoch)
    • Mark as paid all deliveries that ended at or before pay_time.
  5. get_total_cost_unpaid()
    • Return the total cost of all recorded deliveries that have not yet been paid.

Constraints and Assumptions

  • Inputs are valid; concurrency and thread-safety are out of scope.
  • You may discuss and justify time representation (e.g., Unix seconds, ISO-8601 strings, timezone handling) and any assumptions.
  • Demonstrate good OOP practices and share what you would do differently in production.

Constraints & Assumptions

  • Preserve the scope, facts, inputs, and requested outputs from the prompt above.
  • If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
  • Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Rippling•More Software Engineer•Rippling Software Engineer•Rippling System Design•Software Engineer System Design

Your design canvas — auto-saved

PracHub

Master your tech interviews with 9,000+ real questions from top companies.

Product

  • Questions
  • Learning Tracks
  • Interview Guides
  • Resources
  • Premium
  • For Universities

Browse

  • By Company
  • By Role
  • By Category
  • Topic Hubs
  • SQL Questions
  • AI Coding Questions
  • Compare Platforms
  • Discord Community

Support

  • support@prachub.com
  • (916) 541-4762

Legal

  • Privacy Policy
  • Terms of Service
  • About Us

© 2026 PracHub. All rights reserved.