Design API that aggregates three downstream APIs
DoorDashSoftware Engineer · Technical ScreenLast updated
This question evaluates a candidate's ability to design an API aggregator, covering skills in service orchestration, fault tolerance, latency and SLO management, error handling, and observability for distributed HTTP/JSON services.
You are given three existing HTTP JSON APIs owned by other backend services:
- Service A:
GET /service-a?user_id={id}→ returns basic user profile data. - Service B:
GET /service-b?user_id={id}→ returns a list of the user’s recent orders. - Service C:
GET /service-c?user_id={id}→ returns a list of recommended items for the user.
Each service:
- Uses REST over HTTP and returns JSON.
- Has independent latency and failure behavior.
- May return
2xxsuccess,4xxclient errors, or5xxserver errors.
You need to design and implement a new API endpoint (often called an API bootstrap or aggregator) that:
- Exposes a single endpoint, e.g.
GET /bootstrap?user_id={id}. - Internally calls all three existing services.
- Combines their responses into a single JSON response to the client.
- Meets a reasonable latency SLO (for example, p95 < 300 ms).
- Handles partial failures gracefully (e.g., if one service is down).
Assume this will be implemented in a typical backend language (e.g., C++/Java/Go), but focus on the API and system design, not language-specific syntax.
Describe your design in detail, including:
- API contract for the new
/bootstrapendpoint (request parameters and response schema), including how you represent partial failures. - Call orchestration:
- How you will call the three downstream services (in parallel vs sequentially).
- How you will set timeouts and retries.
- Error handling and fallback strategies:
- What you return if one or more downstream services fail or time out.
- How you distinguish between client errors and server errors from downstream services.
- Performance and scalability considerations:
- How your design keeps latency low.
- How the service scales under high QPS.
- Reliability and observability:
- Logging, metrics, and tracing you would add.
- Any use of patterns like circuit breakers or bulkheads.
Explain your reasoning step by step and call out important tradeoffs and edge cases.
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.