Design an API aggregation system across three services

Problem Three existing services each expose an API. Build a system that calls all three, aggregates their documents into a single result, persists it to a database for clients to read, and stays correct end-to-end when any downstream service is slow or failing.

Functional requirements

• Fan out a request to all three services and combine their responses into one aggregated document.
• Persist each aggregated result so clients read it from the store rather than calling the services directly.
• Handle partial failure: a result must still be produced (or retried) when one or more services error or time out.

Non-functional requirements

• Downstream services fail independently; one bad service must not take the whole aggregator down.
• Client reads are far more frequent than aggregation writes and must stay fast.
• Failed or unprocessable aggregations must not be lost silently.

Areas to go deep

• Isolating a slow/failing downstream so it does not exhaust the orchestrator's resources.
• Making the three downstream calls concurrent instead of sequential.
• Where failed messages go, and how the read path scales independently of the write path.