# Design a Resilient Bootstrap API Aggregator Design a bootstrap endpoint that accepts `userId`. A user service returns `customerId`; payment and address services then accept that customer ID and return default-card details and an address. The endpoint aggregates `CustomerId`, `DefaultCard`, and `Address`. Each dependency may return HTTP 500, time out, or throw. ### Constraints & Assumptions - Payment and address calls are independent after customer lookup succeeds. - The API must distinguish complete success from partial data. ### Clarifying Questions to Ask - Which fields are mandatory, and what partial response contract do clients support? - Are retries safe for these read operations and what latency budget applies? ```hint Draw the dependency graph The customer lookup is on the critical path; the two remaining calls can begin together. ``` ### What a Strong Answer Covers - Orchestration, concurrency, deadlines, retries, and cancellation. - An explicit partial-failure response rather than ambiguous defaults. - Observability, testing, and protection against retry storms. ### Follow-up Questions - How would you cache stable fields without serving stale payment data? - How would you evolve the aggregate response safely?