Design a Donation System for a Three-Day Fundraising Campaign

Quick Overview

Design a donation system for a fundraising campaign that runs for exactly three days, where donors choose a charity, pay through a payment processor and see running totals. It tests payment idempotency and reconciliation, handling a time-boxed traffic burst, avoiding write hotspots on totals, and fraud protection.

Design a Donation System for a Three-Day Fundraising Campaign

Company: DoorDash

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Onsite

Design a system that collects donations during a fundraising campaign that runs for three days. Donors pick a charity, choose an amount and pay. The system records every donation and reports how much has been raised. The prompt fixes only the domain and the three-day duration. Establish the remaining requirements with the interviewer before designing. ```hint Money moves through someone else Think about which part of the donation flow you control and which part a payment processor controls. Then ask how the two stay in agreement when a request or a callback is lost. ``` ```hint The calendar is a requirement Ask what a hard three-day window implies: capacity planning before the start, donations still in flight at the end, and work that happens only after the campaign closes. ``` ### Constraints and Clarifications - The campaign has a fixed start and a fixed end, three days apart. - Assume that card payments go through a third-party payment processor, and that the system never stores card numbers. ### Clarifying Questions - Who donates: signed-in users of an existing app, anonymous web visitors, or both? - How many charities take part, and can one donation be split between several of them? - Is a live running total shown to donors? If so, how fresh must it be? - What peak traffic should the design handle, for example right after the campaign is promoted? - Are there minimum or maximum amounts, matching gifts, refunds or tax receipts? - What happens to a payment that is still being confirmed at the moment the campaign closes? ### What a Strong Answer Covers - Requirements and a capacity estimate shaped by a short, bursty, time-boxed event - A payment flow with idempotency, processor callbacks and reconciliation, so no donation is lost or charged twice - A data model with a donation state machine and uniqueness constraints - Running totals that do not turn into a write hotspot - Failure handling for processor outages, lost callbacks and client retries - Abuse protection and the work that happens after the campaign closes (settlement, payouts, refunds) ### Follow-up Questions - How would you add a sponsor who matches donations up to a cap? - The payment processor is down for an hour on day two. What do donors see, and how do you recover? - How would you show a live leaderboard of charities? - After the campaign, how do you prove that the reported total matches the money actually received?

Overview: Design a donation system for a fundraising campaign that runs for exactly three days, where donors choose a charity, pay through a payment processor and see running totals. It tests payment idempotency and reconciliation, handling a time-boxed traffic burst, avoiding write hotspots on totals, and fraud protection.

|Home/System Design/DoorDash
DoorDash logo
DoorDash
Sep 16, 2026
mediumSoftware EngineerOnsiteSystem Design
2
0

Design a system that collects donations during a fundraising campaign that runs for three days. Donors pick a charity, choose an amount and pay. The system records every donation and reports how much has been raised.

The prompt fixes only the domain and the three-day duration. Establish the remaining requirements with the interviewer before designing.

Constraints and Clarifications

  • The campaign has a fixed start and a fixed end, three days apart.
  • Assume that card payments go through a third-party payment processor, and that the system never stores card numbers.

Clarifying Questions Guidance

  • Who donates: signed-in users of an existing app, anonymous web visitors, or both?
  • How many charities take part, and can one donation be split between several of them?
  • Is a live running total shown to donors? If so, how fresh must it be?
  • What peak traffic should the design handle, for example right after the campaign is promoted?
  • Are there minimum or maximum amounts, matching gifts, refunds or tax receipts?
  • What happens to a payment that is still being confirmed at the moment the campaign closes?

What a Strong Answer Covers Guidance

  • Requirements and a capacity estimate shaped by a short, bursty, time-boxed event
  • A payment flow with idempotency, processor callbacks and reconciliation, so no donation is lost or charged twice
  • A data model with a donation state machine and uniqueness constraints
  • Running totals that do not turn into a write hotspot
  • Failure handling for processor outages, lost callbacks and client retries
  • Abuse protection and the work that happens after the campaign closes (settlement, payouts, refunds)

Follow-up Questions Guidance

  • How would you add a sponsor who matches donations up to a cap?
  • The payment processor is down for an hour on day two. What do donors see, and how do you recover?
  • How would you show a live leaderboard of charities?
  • After the campaign, how do you prove that the reported total matches the money actually received?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...