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 Onsite 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 an async donation payment platform | DoorDash Interview Question

Quick Overview

This question evaluates a candidate's ability to design scalable, reliable payment systems and asynchronous processing pipelines, covering competencies in distributed systems, idempotency, data modeling, security/PCI compliance, retry and dead-letter strategies, and observability.

System Design: Online Donation Platform for a 3-Day Campaign

Context

You are designing a donation platform for a time-bounded, high-traffic, three-day campaign. Users provide minimal personal information and donate arbitrary amounts split across multiple organizations. The platform's payment scope is limited to charging donors and depositing funds into the company’s account. No real-time fund-splitting to organizations is required; allocation is recorded for later internal distribution.

Assume:

High burst traffic around campaign marketing pushes.
Use of a third-party payment processor (PSP) that supports idempotent charges and webhooks.
PCI scope is minimized via tokenization/hosted fields.

Requirements

Design an end-to-end architecture and data model. Address:

Synchronous vs asynchronous payment flows; justify when to use async.
Detailed async workflow: API layer, idempotency keys, queue, workers, retries with exponential backoff and jitter, dead-letter handling.
How to guarantee idempotent charges across network retries.
Failure handling, reconciliation/reporting, duplicate submission prevention.
Security/PII and payment compliance, rate limiting, observability, and scaling for bursty traffic.
API contracts, database schema, and a strategy for partial failures and eventual consistency.

Quick Overview

Context

Assume:

High burst traffic around campaign marketing pushes.

Use of a third-party payment processor (PSP) that supports idempotent charges and webhooks.

PCI scope is minimized via tokenization/hosted fields.

Requirements

Design an end-to-end architecture and data model. Address:

Synchronous vs asynchronous payment flows; justify when to use async.

Detailed async workflow: API layer, idempotency keys, queue, workers, retries with exponential backoff and jitter, dead-letter handling.

How to guarantee idempotent charges across network retries.

Failure handling, reconciliation/reporting, duplicate submission prevention.

Security/PII and payment compliance, rate limiting, observability, and scaling for bursty traffic.

API contracts, database schema, and a strategy for partial failures and eventual consistency.

Design an async donation payment platform

Quick Overview

System Design: Online Donation Platform for a 3-Day Campaign

Context

Requirements

Solution

Submit Your Answer

Design an async donation payment platform

Quick Overview

System Design: Online Donation Platform for a 3-Day Campaign

Context

Requirements

Solution

Submit Your Answer