DoorDash·Software Engineer·Onsite - System Design / Architecture·Senior

Senior

Jul 2026

Summary

System design round at DoorDash for a software engineer role, focused entirely on payment reliability. The question was meaty and covered a lot of ground, felt like they wanted to see if you'd actually shipped something like this before.

Questions Asked (1)

You own a courier payout service that submits requests to a downstream payment processor. How do you design the system to handle the payment processor being temporarily down, slow, or flaky, while keeping payouts correct and the user experience reasonable?

System DesignTechnical Trade-offsAPI & Integrations

Author's notes

This question sprawls in every direction if you let it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements: payout correctness is non-negotiable, while user experience can tolerate some delay. Then design an asynchronous, idempotent pipeline with retries, circuit breakers, and a fallback queue, and discuss trade-offs between consistency, latency, and complexity.

Pro tip: Emphasize idempotency keys and exactly-once semantics at the payout level, and mention that you'd monitor the processor's health and degrade gracefully (e.g., queue payouts and notify users) rather than failing hard.

1. Clarify requirements and constraints

Ask about payout volume, latency tolerance, consistency requirements, and whether partial failures are acceptable. Establish that correctness (no double-pay, no lost pay) is paramount.

2. Design for idempotency and exactly-once processing

Use unique idempotency keys for each payout request and ensure the downstream processor supports them. Implement deduplication and state tracking to avoid duplicate payouts on retries.

3. Implement resilient communication patterns

Use retries with exponential backoff and jitter, circuit breakers to fail fast when the processor is down, and timeouts to handle slowness. Consider bulkheads to isolate failures.

4. Handle failures asynchronously with queues and fallbacks

Decouple payout submission from processing via a durable queue. On failure, persist the request and retry later. Provide a fallback processor or manual review for critical cases.

5. Ensure observability and user experience

Monitor processor health, alert on failures, and expose payout status to users. Communicate delays transparently and allow cancellation if needed.

Key Points to Mention

Idempotency keys and exactly-once semantics to prevent duplicate payouts
Retry strategies with exponential backoff and jitter, and circuit breakers
Asynchronous processing with durable queues and dead-letter queues
State machine for payout lifecycle (pending, processing, succeeded, failed)
Monitoring, alerting, and graceful degradation (e.g., queue and notify users)
Trade-offs between consistency, availability, and latency (CAP theorem)

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.