How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a medium difficulty System Design question, commonly asked during Technical Screen rounds at DoorDash.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at DoorDash during technical interviews.

Design API that aggregates three downstream APIs

Q: Design API that aggregates three downstream APIs

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.

Company: DoorDash

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Technical Screen

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 `2xx` success, `4xx` client errors, or `5xx` server 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: 1. **API contract** for the new `/bootstrap` endpoint (request parameters and response schema), including how you represent partial failures. 2. **Call orchestration**: - How you will call the three downstream services (in parallel vs sequentially). - How you will set timeouts and retries. 3. **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. 4. **Performance and scalability considerations**: - How your design keeps latency low. - How the service scales under high QPS. 5. **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.

Quick Answer: 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 2xx success, 4xx client errors, or 5xx server 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 /bootstrap endpoint (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.

Design API that aggregates three downstream APIs

Company: DoorDash

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Technical Screen

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 2xx success, 4xx client errors, or 5xx server 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 /bootstrap endpoint (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.

Design API that aggregates three downstream APIs

Quick Overview

Solution

Comments (0)

Design API that aggregates three downstream APIs

Quick Overview

Solution

Comments (0)