Aggregate Internal Services with Critical and Optional Dependencies

Read the full interview experience this question came from →

Quick Overview

Build a typed aggregation endpoint that remains useful when optional services fail. Define partial responses, shared deadlines, testable adapters, bounded retries, and circuit-breaker behavior.

Aggregate Internal Services with Critical and Optional Dependencies

Company: DoorDash

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Onsite

Build a backend endpoint that calls multiple internal services and aggregates their data into one response. Some dependencies are critical; if a noncritical service fails, return a useful partial response. Use clear strongly typed models and make the code testable. Discuss retries, jittered backoff, and circuit breakers. ### Clarifying Questions Identify which fields require each dependency, which failures prevent a valid response, and the overall deadline. The concrete services and schema are unspecified. For a worked example, choose a required profile service and an optional recommendations service, labeling these as practice choices. ### What a Strong Answer Covers Typed dependency interfaces, bounded concurrent calls, deadline propagation, explicit partial-result metadata, retry classification, circuit behavior, and tests with controlled dependency outcomes. ### Follow-up Questions - Why is an empty recommendation list different from an unavailable recommendations service? - How can retries make an overloaded service less available?

Overview: Build a typed aggregation endpoint that remains useful when optional services fail. Define partial responses, shared deadlines, testable adapters, bounded retries, and circuit-breaker behavior.

Read the full DoorDash Software Engineer interview experience this question came from

DoorDash logo
DoorDash
Oct 23, 2026
mediumSoftware EngineerOnsiteSoftware Engineering Fundamentals
0
0

Build a backend endpoint that calls multiple internal services and aggregates their data into one response. Some dependencies are critical; if a noncritical service fails, return a useful partial response. Use clear strongly typed models and make the code testable. Discuss retries, jittered backoff, and circuit breakers.

Clarifying Questions Guidance

Identify which fields require each dependency, which failures prevent a valid response, and the overall deadline. The concrete services and schema are unspecified. For a worked example, choose a required profile service and an optional recommendations service, labeling these as practice choices.

What a Strong Answer Covers Guidance

Typed dependency interfaces, bounded concurrent calls, deadline propagation, explicit partial-result metadata, retry classification, circuit behavior, and tests with controlled dependency outcomes.

Follow-up Questions Guidance

  • Why is an empty recommendation list different from an unavailable recommendations service?
  • How can retries make an overloaded service less available?