Design a scalable donation system with reliable payment processing

Read the full interview experience this question came from →

Quick Overview

Design a donation system that charges donors through a payment provider, records every donation exactly once and shows how much each fundraiser has raised. It tests payment idempotency, ledgers, provider callbacks and reconciliation, and how the design keeps scaling when one fundraiser suddenly draws heavy traffic.

Design a scalable donation system with reliable payment processing

Company: Whatnot

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Onsite

Design a donation system: people give money to a cause or fundraiser, the system charges their payment method, records every donation, and shows donors and organizers how much has been raised. The report gives only the name of the problem, and notes that the interviewer kept returning to the same question about how the design scales, so be ready to defend your scaling choices more than once. Settle the scope and scale with the interviewer before designing. ```hint Money moves once Think about what happens when the payment provider times out and the donor presses the button again. ``` ```hint Find the hottest record Ask which single record receives the most writes when one fundraiser suddenly becomes popular, and whether the page really needs that number to be exact to the second. ``` ### Clarifying Questions - Do donors need accounts, or can guests give? Are donations one-time only, or recurring too? - Is card processing handled by a third-party payment provider? - How many donations per second arrive normally and at peak, and is the peak concentrated on one fundraiser, for example during a live event? - Must the raised total be exact in real time, or may it lag by a few seconds? - Which money flows are in scope: receipts, refunds, payouts to organizers or charities, several currencies? - What fraud must be prevented? ### What a Strong Answer Covers - Functional and non-functional requirements and estimates, separating the read peak from the write peak - APIs and a data model with donations, a ledger and a display projection of totals - A payment flow that never charges twice: idempotency keys, a state machine, provider callbacks and reconciliation - Totals that stay fast and correct when one fundraiser receives most of the donations - A scaling plan for each component, stated as firm choices with their rationale - Refunds and payouts, fraud defenses, failure handling and observability ### Follow-up Questions - One fundraiser suddenly receives most of the site's traffic. What breaks first, and how do you fix it? - The payment provider charged a donor, but your service crashed before recording it. How do you find and fix the gap? - How would you support monthly recurring donations? - How do you issue refunds and keep the organizer's payout correct?

Overview: Design a donation system that charges donors through a payment provider, records every donation exactly once and shows how much each fundraiser has raised. It tests payment idempotency, ledgers, provider callbacks and reconciliation, and how the design keeps scaling when one fundraiser suddenly draws heavy traffic.

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

Whatnot logo
Whatnot
Nov 10, 2026
mediumSoftware EngineerOnsiteSystem Design
0
0

Design a donation system: people give money to a cause or fundraiser, the system charges their payment method, records every donation, and shows donors and organizers how much has been raised. The report gives only the name of the problem, and notes that the interviewer kept returning to the same question about how the design scales, so be ready to defend your scaling choices more than once. Settle the scope and scale with the interviewer before designing.

Clarifying Questions Guidance

  • Do donors need accounts, or can guests give? Are donations one-time only, or recurring too?
  • Is card processing handled by a third-party payment provider?
  • How many donations per second arrive normally and at peak, and is the peak concentrated on one fundraiser, for example during a live event?
  • Must the raised total be exact in real time, or may it lag by a few seconds?
  • Which money flows are in scope: receipts, refunds, payouts to organizers or charities, several currencies?
  • What fraud must be prevented?

What a Strong Answer Covers Guidance

  • Functional and non-functional requirements and estimates, separating the read peak from the write peak
  • APIs and a data model with donations, a ledger and a display projection of totals
  • A payment flow that never charges twice: idempotency keys, a state machine, provider callbacks and reconciliation
  • Totals that stay fast and correct when one fundraiser receives most of the donations
  • A scaling plan for each component, stated as firm choices with their rationale
  • Refunds and payouts, fraud defenses, failure handling and observability

Follow-up Questions Guidance

  • One fundraiser suddenly receives most of the site's traffic. What breaks first, and how do you fix it?
  • The payment provider charged a donor, but your service crashed before recording it. How do you find and fix the gap?
  • How would you support monthly recurring donations?
  • How do you issue refunds and keep the organizer's payout correct?