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 hard difficulty System Design question, commonly asked during Technical Screen rounds at DoorDash.

What role is this question designed for?

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

Design a resilient dasher payment system | DoorDash Interview Question

Quick Overview

This question evaluates system design and distributed-systems competencies including event-driven architecture, ingestion semantics (idempotency and delivery guarantees), high-throughput data modeling, streaming versus batch payout computation, data quality and remediation workflows, API and timezone handling, and operational monitoring.

System Design: End-to-End Payouts from Order Lifecycle Events

You are designing a system that computes delivery driver (Dasher) payouts from an event stream of order lifecycle events. The stream includes only two event types:

ACCEPT(orderId, dasherId, timestamp)
FULFILL(orderId, dasherId, timestamp)

Assume the happy path input is valid (each order is accepted then fulfilled by the same dasher exactly once in-order). You must design for scale (high write throughput) and correctness, and proactively address failure modes.

Requirements

Event ingestion and semantics
- Define ingestion semantics for ACCEPT and FULFILL events.
- Explain idempotency, deduplication, and trade-offs among exactly-once vs at-least-once delivery.
Data models and storage
- Propose data models to support:
  - High write throughput for raw events and derived state.
  - Efficient payout queries per dasher and pay period.
  - Backfills and reprocessing.
- Specify storage choices (e.g., event log, OLTP/NoSQL, data lake), partitioning, and indexing.
Computation of payouts
- Describe how payouts are computed from the lifecycle (e.g., payout triggered at FULFILL, adjustments, etc.).
- Outline batch vs streaming computation, how to finalize a pay period, and how to support backfills and reconciliation.
Data quality and remediation
- Proactively detect and remediate data loss/corruption:
  - FULFILL arrives without a prior ACCEPT.
  - ACCEPT has no subsequent FULFILL.
  - Duplicate events.
  - Out-of-order delivery.
- Define SLAs, dead-letter queues, and correction strategies.
APIs
- Define APIs for:
  - Event ingestion (ACCEPT/FULFILL).
  - Querying a dasher’s payout for a given local pay period.
- Explain handling of timezone and Daylight Saving Time (DST).
Monitoring, alerting, and correctness
- Define key metrics, alerts, and correctness checks.
- Be explicit about trade-offs and consistency guarantees.

Quick Overview

System Design: End-to-End Payouts from Order Lifecycle Events

You are designing a system that computes delivery driver (Dasher) payouts from an event stream of order lifecycle events. The stream includes only two event types:

ACCEPT(orderId, dasherId, timestamp)

FULFILL(orderId, dasherId, timestamp)

Requirements

Event ingestion and semantics

Define ingestion semantics for ACCEPT and FULFILL events.
Explain idempotency, deduplication, and trade-offs among exactly-once vs at-least-once delivery.

Data models and storage

Propose data models to support:
- High write throughput for raw events and derived state.
- Efficient payout queries per dasher and pay period.
- Backfills and reprocessing.
Specify storage choices (e.g., event log, OLTP/NoSQL, data lake), partitioning, and indexing.

Computation of payouts

Describe how payouts are computed from the lifecycle (e.g., payout triggered at FULFILL, adjustments, etc.).
Outline batch vs streaming computation, how to finalize a pay period, and how to support backfills and reconciliation.

Data quality and remediation

Proactively detect and remediate data loss/corruption:
- FULFILL arrives without a prior ACCEPT.
- ACCEPT has no subsequent FULFILL.
- Duplicate events.
- Out-of-order delivery.
Define SLAs, dead-letter queues, and correction strategies.

APIs

Define APIs for:
- Event ingestion (ACCEPT/FULFILL).
- Querying a dasher’s payout for a given local pay period.
Explain handling of timezone and Daylight Saving Time (DST).

Monitoring, alerting, and correctness

Define key metrics, alerts, and correctness checks.
Be explicit about trade-offs and consistency guarantees.

Design a resilient dasher payment system

Quick Overview

System Design: End-to-End Payouts from Order Lifecycle Events

Requirements

Solution

Comments (0)

Design a resilient dasher payment system

Quick Overview

System Design: End-to-End Payouts from Order Lifecycle Events

Requirements

Solution

Comments (0)