You are given three existing HTTP JSON APIs owned by other backend services: - **Service A:** `GET /service-a?user_id={id}` → returns basic user profile data. - **Service B:** `GET /service-b?user_id={id}` → returns a list of the user’s recent orders. - **Service C:** `GET /service-c?user_id={id}` → returns a list of recommended items for the user. Each service: - Uses REST over HTTP and returns JSON. - Has independent latency and failure behavior. - May return `2xx` success, `4xx` client errors, or `5xx` server errors. You need to design and implement a **new API endpoint** (often called an API bootstrap or aggregator) that: - Exposes a single endpoint, e.g. `GET /bootstrap?user_id={id}`. - Internally calls all three existing services. - Combines their responses into a single JSON response to the client. - Meets a reasonable latency SLO (for example, p95 < 300 ms). - Handles partial failures gracefully (e.g., if one service is down). Assume this will be implemented in a typical backend language (e.g., C++/Java/Go), but focus on the **API and system design**, not language-specific syntax. **Describe your design in detail**, including: 1. **API contract** for the new `/bootstrap` endpoint (request parameters and response schema), including how you represent partial failures. 2. **Call orchestration**: - How you will call the three downstream services (in parallel vs sequentially). - How you will set timeouts and retries. 3. **Error handling and fallback strategies**: - What you return if one or more downstream services fail or time out. - How you distinguish between client errors and server errors from downstream services. 4. **Performance and scalability considerations**: - How your design keeps latency low. - How the service scales under high QPS. 5. **Reliability and observability**: - Logging, metrics, and tracing you would add. - Any use of patterns like circuit breakers or bulkheads. Explain your reasoning step by step and call out important tradeoffs and edge cases.