Design limited-time donation platform

Read the full interview experience this question came from →

Quick Overview

This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design limited-time donation platform states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design limited-time donation platform

Company: DoorDash

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Design a donations platform for a three-day global fundraising campaign. Specify functional APIs (create donation, confirm payment, refund, totals), data model, idempotency for payment retries, real-time running totals/leaderboards, fraud/deduplication checks, rate limiting, backpressure, and handling delayed webhooks. Address scalability for traffic spikes, availability across regions, consistency trade-offs, storage/partitioning strategy, caching, streaming for analytics, observability, and failure scenarios (provider outage, double-submits). Provide capacity estimates and a rollout/testing plan.

Overview: This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design limited-time donation platform states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

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

|Home/DoorDash/System Design
DoorDash logo
DoorDash
Aug 9, 2025
hardSoftware EngineerTechnical ScreenSystem Design
13
0

Design limited-time donation platform

System Design: Donations Platform for a Three-Day Global Fundraising Campaign

Context

You are to design an internet-scale donations platform for a time-bounded, three-day global fundraising campaign. The platform must handle significant traffic spikes during live events, provide real-time visibility into totals and leaderboards, ensure payment correctness, and remain highly available across regions.

Requirements

Design and specify the following:

  1. Functional APIs
    • Create donation (intent), confirm payment, refund.
    • Query: totals and leaderboards (by campaign, country, team, etc.).
  2. Data model
    • Core entities (campaign, donation, payment, refund, donor/PII segregation, ledger), indexes, and unique constraints.
  3. Idempotency and deduplication
    • Strategy for client retries and provider webhook retries; prevention of double-submits.
  4. Real-time totals and leaderboards
    • Running totals with sub-second updates; unique donors, top teams/countries.
  5. Risk controls
    • Fraud checks and deduplication heuristics; velocity limits.
  6. Traffic protection
    • Rate limiting, backpressure, and load shedding.
  7. Webhooks
    • Handling delayed/out-of-order/duplicated payment provider webhooks and reconciliation.
  8. Scalability and availability
    • Design for global traffic spikes; multi-region availability; explicit consistency trade-offs.
  9. Storage and partitioning
    • OLTP vs. streaming/warehouse; partitioning, replication, and hot campaign handling.
  10. Caching
    • Strategy for campaign config, totals, and leaderboards.
  11. Streaming and analytics
    • Near-real-time pipelines for metrics and BI.
  12. Observability
    • Metrics, logs, traces, dashboards, and alerting.
  13. Failure scenarios
    • Payment provider outage, double-submits, partial failures; recovery and user experience.
  14. Capacity estimates
    • Back-of-the-envelope RPS/QPS, storage, throughput; latency budgets.
  15. Rollout and testing
    • Phased rollout, load tests, chaos/failure drills, and monitoring gates.

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Browse More Questions

More System Design•More DoorDash•More Software Engineer•DoorDash Software Engineer•DoorDash System Design•Software Engineer System Design