Build a Resilient Bootstrap API with Partial Upstream Results

Implement the design of a resilient bootstrap API that accepts `user_id` and combines information from three existing upstream services. Boilerplate and mock services are available. ### Requirements and Constraints - Consumer accepts `user_id` and returns user information including `consumer_id` and roles. - Payment accepts `consumer_id` and returns the default card and available gift-card credit. - Address accepts `consumer_id` and returns the formatted address, first name, and last name. - `user_id` and `consumer_id` are different identifiers. - Consumer failure may make the bootstrap request fail with HTTP 500. - Payment or Address failure must preserve the remaining available information. - The result must include the required address name fields when Address succeeds. Explain the call sequence, response structure, HTTP and timeout handling, and the tests needed to demonstrate the required behavior. This is a service-integration exercise; no real upstream endpoint or response schema beyond the listed fields is supplied. ### Clarifying Questions - Which non-success status codes can each upstream return, and which ones mean the upstream data is absent rather than temporarily unavailable? - How should the bootstrap response represent an unavailable optional section: omission, null, or a structured error? - What total request deadline and per-upstream timeouts are acceptable? - Are the upstream operations safe to retry, and would retrying fit within the caller's remaining deadline? ```hint Draw the identifier dependency The optional services do not take the bootstrap API's original identifier. Establish which successful result supplies the identifier they require before choosing the parallel calls. ``` ### What a Strong Answer Covers - Consumer-first dependency resolution followed by independent Payment and Address calls using the returned `consumer_id`. - Explicit status-code validation and parsing or transport error handling. - Partial success for each optional-service failure combination, without silently dropping successful Consumer information. - A complete field mapping, including first and last names from Address. - A bounded timeout and retry policy and a response contract that distinguishes missing information from a real zero balance. - Tests of normal behavior, each upstream failure, both optional failures, wrong identifier use, and unexpected payloads. ### Follow-up Questions 1. What should the response contain when Consumer and Payment succeed but Address fails? 2. What should happen when both optional services time out after Consumer succeeds? 3. Why might catching exceptions alone fail to detect an upstream HTTP 500 response?