# Implement a Resilient Aggregator over Three Services You are given template code with clients for three existing services: a user service, a payment service, and an address service. Implement an aggregation layer that calls the supplied clients and returns one combined response. The source does not preserve the clients' method names, parameters, dependency ordering, or failure contract. Present a runnable, self-contained example around minimal typed adapter interfaces, and label those interface and policy choices as illustrative assumptions rather than facts about the supplied template. Explain how you would inspect and adapt to the real contracts. ### Constraints & Assumptions - The supplied service clients are the integration boundary; do not duplicate their transport logic in the aggregator. - Determine from the supplied interfaces whether calls are independent or whether one result supplies an input to another; parallelize only independent work. - Choose and document an all-or-nothing or explicit partial-result contract for the runnable example because the source does not specify one. ### Clarifying Questions to Ask - Is the combined response all-or-nothing, or may it contain successful sections plus explicit per-service errors? - What timeout and retry behavior already exists in each provided client? - What inputs does each supplied client require, and does one call depend on another call's result? ```hint Separate orchestration from transport Let each provided client own its protocol details while the aggregator owns concurrency, policy, and response assembly. ``` ```hint Preserve failure identity A single generic null cannot distinguish a service timeout from a valid empty result or an authorization denial. ``` ### What a Strong Answer Covers - Parallel execution only for calls proven independent by the supplied contracts, plus a deliberate all-or-nothing or partial-response policy. - Input validation appropriate to the actual adapters, deadlines, cancellation, and bounded retries. - Typed assembly that cannot accidentally swap or mislabel service results. - Tests for success, one-service failure, timeout, malformed upstream data, and cancellation. - Clear latency analysis based on the slowest concurrent call rather than the sum of all three. ### Follow-up Questions - How would you prevent a slow abandoned request from continuing all three upstream calls? - Where would caching be safe, and which sections need especially careful authorization and freshness rules? - How would you trace one aggregate request across all three services without logging sensitive payloads?