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 hard 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 a service aggregator with robust error handling

Quick Overview

Design a service aggregator with robust error handling evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design a service aggregator with robust error handling

System Design: HTTP Aggregator With Deadlines, Resilience, and Observability

Context

Build an HTTP aggregator that fans out to three independent downstream services in parallel and returns a single consolidated JSON response. Assume the downstreams are:

Service A: User Profile
Service B: Recent Orders
Service C: Recommendations

The aggregator must be production-grade with strong reliability, performance, and observability guarantees.

Requirements

API design
- Define the aggregator's request schema, response schema, and HTTP status codes.
- Show how missing/erroneous sub-responses are represented in the final JSON.
Concurrency and timeboxing
- Call A, B, C in parallel.
- Define per-call timeouts and a global deadline (e.g., 300 ms) so a slow service does not block the whole request.
- If the global deadline is exceeded, cancel in-flight work and return a degraded but well-formed response.
Resilience
- Handle errors and partial failures with retries (exponential backoff + jitter), circuit breaking, and sensible fallbacks/defaults.
- Ensure idempotency and avoid duplicating side effects on retries.
Merging logic
- Describe how to merge the payloads (A=user profile, B=recent orders, C=recommendations) into one response.
Resource management and isolation
- Discuss concurrency model, thread safety, resource limits (connection pools), rate limiting, and bulkheading.
Observability
- Outline logging, metrics, and distributed tracing (including correlation IDs) for end-to-end visibility.
Testing
- Describe the testing plan (unit, integration), including timeouts, cancellations, retries, partial failures, and circuit breaking.
Code and structure
- Provide production-grade naming and code structure (modules/classes).
- Include pseudocode or code in a language of your choice implementing the handler and fan-out/fan-in with cancellation and retries.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?

Quick Overview

Context

Build an HTTP aggregator that fans out to three independent downstream services in parallel and returns a single consolidated JSON response. Assume the downstreams are:

Service A: User Profile

Service B: Recent Orders

Service C: Recommendations

The aggregator must be production-grade with strong reliability, performance, and observability guarantees.

Requirements

API design

Define the aggregator's request schema, response schema, and HTTP status codes.
Show how missing/erroneous sub-responses are represented in the final JSON.

Concurrency and timeboxing

Call A, B, C in parallel.
Define per-call timeouts and a global deadline (e.g., 300 ms) so a slow service does not block the whole request.
If the global deadline is exceeded, cancel in-flight work and return a degraded but well-formed response.

Resilience

Handle errors and partial failures with retries (exponential backoff + jitter), circuit breaking, and sensible fallbacks/defaults.
Ensure idempotency and avoid duplicating side effects on retries.

Merging logic

Describe how to merge the payloads (A=user profile, B=recent orders, C=recommendations) into one response.

Resource management and isolation

Discuss concurrency model, thread safety, resource limits (connection pools), rate limiting, and bulkheading.

Observability

Outline logging, metrics, and distributed tracing (including correlation IDs) for end-to-end visibility.

Testing

Describe the testing plan (unit, integration), including timeouts, cancellations, retries, partial failures, and circuit breaking.

Code and structure

Provide production-grade naming and code structure (modules/classes).
Include pseudocode or code in a language of your choice implementing the handler and fan-out/fan-in with cancellation and retries.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.

If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.

Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.

State explicit assumptions before making sizing or architecture decisions.

Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.

API, data model, architecture, consistency, capacity, and operations.

Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.

A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?

How would you degrade gracefully during dependency failures?

What metrics and alerts would prove the design is healthy after launch?

Design a service aggregator with robust error handling

Quick Overview

Design a service aggregator with robust error handling

Design a service aggregator with robust error handling

System Design: HTTP Aggregator With Deadlines, Resilience, and Observability

Context

Requirements

Constraints & Assumptions

Clarifying Questions to Ask Guidance

What a Strong Answer Covers Guidance

Follow-up Questions Guidance

Submit Your Answer to Earn 20XP

Design a service aggregator with robust error handling

Quick Overview

Design a service aggregator with robust error handling

Design a service aggregator with robust error handling

System Design: HTTP Aggregator With Deadlines, Resilience, and Observability

Context

Requirements

Constraints & Assumptions

Clarifying Questions to Ask Guidance

What a Strong Answer Covers Guidance

Follow-up Questions Guidance

Submit Your Answer to Earn 20XP