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

SeniorPrefer not to say

May 2026

Summary

DoorDash system design round, one big question that sprawled into like six different topics. Felt manageable at first and then the scope just kept expanding.

Questions Asked (1)

Design an HTTP aggregator service that fans out requests to three downstream services in parallel and returns a single merged JSON response. Cover the request/response schema, status codes, timeout strategy, error handling with retries and circuit breaking, partial failure fallbacks, concurrency model, observability, and how you'd test it.

System DesignAPI & IntegrationsTechnical Trade-offs

Author's notes

This is the whole interview in one question.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and defining the API contract, then walk through the architecture layer by layer: request handling, parallel fan-out with timeouts, resilience patterns (retries, circuit breakers, fallbacks), and observability. Emphasize trade-offs at each decision point, especially around partial failures and consistency, and finish with a concrete testing strategy.

Pro tip: Anchor your design around the user experience: decide upfront whether partial results are acceptable and how to signal them (e.g., 200 with partial data vs. 207 Multi-Status), because this drives your timeout, retry, and fallback strategies. Also, mention idempotency and request coalescing to avoid duplicate downstream calls under retries.

1. Clarify requirements and define the API contract

Ask about expected latency, downstream SLAs, data consistency needs, and whether partial responses are acceptable. Then specify the request schema (e.g., query params or body with downstream identifiers) and the merged response schema, including a metadata section for per-service status and errors.

2. Design the fan-out and concurrency model

Use a non-blocking I/O model (e.g., async/await, CompletableFuture, or goroutines) to issue all three downstream calls in parallel. Set a global timeout for the aggregator and per-call timeouts, and use a bounded thread pool or event loop to avoid resource exhaustion.

3. Implement resilience: retries, circuit breakers, and fallbacks

Apply retries with exponential backoff and jitter only for idempotent requests, and use a circuit breaker per downstream service to fail fast when error rates spike. Define fallback behavior: return cached data, default values, or omit the section with a clear error indicator in the response.

4. Define status codes and error handling

Return 200 OK if all downstream calls succeed, 207 Multi-Status if some fail but partial data is returned, and 503 Service Unavailable if all fail or the aggregator itself is overloaded. Include a structured error object per failed service in the response body.

5. Add observability and testing strategy

Instrument with metrics (latency, error rates, circuit breaker state), distributed tracing (e.g., OpenTelemetry), and structured logging with correlation IDs. For testing, cover unit tests with mocked downstreams, integration tests with fault injection (timeouts, errors), and load tests to validate concurrency and timeout behavior.

Key Points to Mention

Timeout strategy: global deadline vs. per-call timeouts, and how to cancel outstanding requests when the global deadline is hit.
Retry policy: exponential backoff with jitter, retry budgets, and idempotency keys to avoid duplicate side effects.
Circuit breaker pattern: states (closed, open, half-open), thresholds, and fallback behavior when open.
Partial failure handling: response schema with per-service status, HTTP 207 Multi-Status, and fallback data sources (cache, defaults).
Concurrency model: non-blocking I/O, thread pool sizing, backpressure, and resource isolation per downstream.
Observability: metrics (RED method), distributed tracing, logging with correlation IDs, and alerting on circuit breaker trips.

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