Katkat
Back

Design a Charity Donation Website

WhatnotSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Tests your ability to architect a resilient, high-throughput charity donation platform with strict payment idempotency, asynchronous transaction processing, real-time campaign counters, and financial auditability.

Scenario

Design the backend infrastructure for a high-traffic charity donation platform that powers live charity drives and creator-led fundraising streams. The system must support bursty donation traffic, integrate securely with external payment gateways, prevent duplicate charges, and provide real-time donation feeds and campaign totals.

Requirements

Functional Requirements

  • Campaign Management: Charities can create campaigns with fundraising goals and end dates. Donors can view campaign details.
  • Donation Processing: Users can donate arbitrary amounts to a campaign using credit cards or stored payment methods, with automated tax-deductible receipts issued via email.
  • Real-Time Feed & Totals: Each campaign displays a live ticker of recent donors and an up-to-date total raised (within 1–2 seconds of confirmed donation).
  • Audit & Reporting: Immutable ledger entries for all transactions, chargebacks, and payouts.

Non-Functional Requirements

  • Zero Double Charging: Guarantee strict idempotency across retries, network dropouts, and accidental multi-clicks.
  • High Availability & Fault Tolerance: 99.99% availability during live broadcast donation drives.
  • Data Consistency: Financial ledgers must be strictly consistent; campaign counters can be eventually consistent within 2 seconds.
  • Security & Compliance: PCI-DSS compliance (no raw card data on internal servers), fraud mitigation, and data encryption at rest and in transit.

Scale & Numbers

  • Campaigns: 10,000 active campaigns at any time.
  • Peak Traffic: During live creator charity streams, single campaigns can experience bursts of up to 5,000 donations per second.
  • Read Traffic: Up to 100,000 concurrent viewers watching campaign progress and donor feeds.

What to Cover

  1. Core API Endpoints: Define contracts for initiating a donation, processing payment webhooks, and fetching campaign statistics.
  2. Data Modeling: Schema design for campaigns, users, transactions, and immutable financial ledger entries.
  3. Payment Architecture & Idempotency: Detail the step-by-step payment lifecycle, handling payment gateway integration, idempotency keys, and asynchronous webhook processing.
  4. High-Throughput Aggregation: How to reliably increment campaign totals and broadcast live updates without creating database row-lock contention.
  5. Failure Modes & Edge Cases: Gateway timeouts, out-of-order webhooks, and reconciliation jobs.

Hints

Hint 1

Use client-generated idempotency keys with unique database constraints and Redis locks to prevent duplicate charge attempts.

Hint 2

Decouple payment authorization from campaign aggregation using a durable event bus like Apache Kafka or AWS SQS.

Hint 3

Avoid updating a single campaign row directly on every transaction; aggregate counts in-memory or in Redis, persisting deltas to the primary database via scheduled batch writes.

Follow-up questions

  • How do you handle race conditions where an asynchronous payment gateway webhook arrives before your initial transaction record is committed?
  • If the external payment gateway experiences an outage, what circuit-breaking and user-facing retry strategies would you implement?
  • How would you design the nightly financial reconciliation system to detect discrepancies between gateway settlement reports and internal database records?