Design an async donation payment platform

Read the full interview experience this question came from →

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.

Design an async donation payment platform

Company: DoorDash

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design an online donation platform for a three-day campaign. Users submit personal info and choose amounts to donate to multiple organizations, but your service only needs to charge users and deposit funds into the company’s account. Specify an end-to-end architecture and data model; compare synchronous vs asynchronous payment flows and justify when to use async. Detail an async workflow (API layer, idempotency keys, queue, workers, retries with backoff, dead-letter handling) and how you guarantee idempotent charges across network retries. Cover failure handling, reconciliation/reporting, duplicate submission prevention, security/PII and payment compliance, rate limiting, observability, and scaling for bursty traffic. Provide API contracts, database schema, and a strategy for partial failures and eventual consistency.

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.

Read the full DoorDash Software Engineer interview experience this question came from

|Home/System Design/DoorDash
DoorDash logo
DoorDash
Sep 6, 2025
hardSoftware EngineerOnsiteSystem Design
10
0

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:

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

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...