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

Senior

May 2026

Summary

DoorDash system design round focused on a deceptively practical API orchestration problem. The setup was clean but the failure-handling requirements made it way more involved than it first looked.

Questions Asked (1)

You have three internal APIs: one that resolves a user ID to a consumer ID, one that fetches payment info given a consumer ID, and one that fetches address info given a consumer ID. Build a bootstrap endpoint that returns all four fields combined, calling the payment and address APIs in parallel after the first call resolves, with timeouts, retries with exponential backoff, and graceful partial responses when the payment or address call fails permanently. If the first call fails, the whole thing fails.

System DesignAPI & IntegrationsTechnical Trade-offs

Author's notes

The parallel calls part I got pretty quickly, just fan out after the first resolves and wait on both.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then outline a high-level design that sequences the calls correctly: first resolve user ID to consumer ID, then parallelize payment and address calls. Dive into resilience patterns like timeouts, retries with exponential backoff, and partial failure handling, and discuss trade-offs and monitoring.

Pro tip: Emphasize idempotency and observability: ensure retries are safe and include logging/metrics for each downstream call to quickly diagnose issues. Also, consider using a circuit breaker to prevent cascading failures.

1. Clarify Requirements and Constraints

Ask about expected latency, error handling expectations, and whether partial responses are acceptable. Confirm that the first call is critical and must succeed.

2. Design the Call Flow

Outline the sequential first call to resolve consumer ID, then parallel calls to payment and address APIs. Use asynchronous or concurrent execution to minimize latency.

3. Implement Resilience Patterns

Apply timeouts to each call, retries with exponential backoff and jitter for transient failures, and define fallback behavior for permanent failures (e.g., return partial data with error indicators).

4. Handle Errors and Partial Responses

If the first call fails, return an error. If payment or address fails after retries, return the successful fields and mark the failed ones as unavailable, with appropriate status codes or error details.

5. Discuss Trade-offs and Monitoring

Talk about trade-offs between consistency and availability, retry budgets, and how to monitor and alert on failures. Mention idempotency keys for retries and logging for debugging.

Key Points to Mention

Timeouts and retries with exponential backoff and jitter to avoid thundering herd
Parallel execution of payment and address calls using async/await or futures
Graceful degradation: returning partial data with clear error indicators when a non-critical call fails
Idempotency of retries to prevent duplicate side effects
Circuit breaker pattern to prevent cascading failures
Observability: logging, metrics, and tracing for each downstream call

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