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

Company: DoorDash

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Design and implement an HTTP aggregator that calls three independent downstream services (A, B, C) in parallel and returns a single consolidated JSON response. Specify the aggregator's request/response schema and status codes. Define per-call timeouts and a global deadline (e.g., 300 ms) so one slow service does not block the whole request. Handle errors and partial failures with retries (with backoff/jitter), circuit breaking, and sensible fallbacks/defaults; ensure idempotency and do not duplicate side effects on retries. If the global deadline is exceeded, cancel in-flight work and return a degraded but well-formed response. Describe how you merge the three payloads (e.g., A=user profile, B=recent orders, C=recommendations) and how you represent missing/erroneous sub-responses in the final JSON. Discuss concurrency model, thread safety, resource limits (connection pools), rate limiting, and bulkheading. Outline logging, metrics, and distributed tracing for observability (including correlation IDs) and what you would test (unit/integration, timeouts, partial failures). Provide production-grade naming and code structure (modules/classes) and include pseudocode or code in a language of your choice.

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.

|Home/System Design/DoorDash
DoorDash logo
DoorDash
Jul 26, 2025
hardSoftware EngineerTechnical ScreenSystem Design
8
0

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

  1. 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.
  2. 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.
  3. 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.
  4. Merging logic
    • Describe how to merge the payloads (A=user profile, B=recent orders, C=recommendations) into one response.
  5. Resource management and isolation
    • Discuss concurrency model, thread safety, resource limits (connection pools), rate limiting, and bulkheading.
  6. Observability
    • Outline logging, metrics, and distributed tracing (including correlation IDs) for end-to-end visibility.
  7. Testing
    • Describe the testing plan (unit, integration), including timeouts, cancellations, retries, partial failures, and circuit breaking.
  8. 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.

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?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...