A sequential description would be (1) one request to retrieve some state followed by (2) n requests to retrieve analytics based on the passed in state followed by (3) the aggregation of the information retrieved by the n requests followed by (4) a notification sent to the service initiating the request for aggregated analytics.

The transition from (1) to (2) is straight forward it can be implemented following observer design pattern, have a singleton observable service retrieving a state notifying its observers once the state is consistent. The transition from (2) to (3) is the reverse of observer design pattern, multiple observable services notifying one observer, the aggregator service, that uses builder design pattern to aggregate data. The transition from (3) to (4) is observer design pattern with the builder notifying the its observer with the aggregated data.

The tricky piece is to trigger the data aggregation. It has to support service failure and aggregate partial analytics in case of non-responsive analytics services. Since I don't have knowledge of a suitable design pattern, let's improvise and implement an observable service that supports instance per call and that guarantees notifying its observer regardless of the result of the call to the external service. Then have created an instance of early described service for each analytics to be retrieved with the aggregator service instance observing it. Then the aggregator service instance has to have a stack of no-op of size n - 1 so the nth notification triggers the aggregation or has to support a state diagram and with each notification advance the state until the aggregation. With the side note that the aggregator service also has to support instance per call.

Now some hazardous advertising, maybe Spring Webflux is what you are searching for.

A sequential description would be (1) one request to retrieve some state followed by (2) n requests to retrieve analytics based on the passed in state followed by (3) the aggregation of the information retrieved by the n requests followed by (4) a notification sent to the service initiating the request for aggregated analytics.

The transition from (1) to (2) is straight forward it can be implemented following observer design pattern, have a singleton observable service retrieving a state notifying its observers once the state is consistent. The transition from (2) to (3) is the reverse of observer design pattern, multiple observable services notifying one observer, the aggregator service, that uses builder design pattern to aggregate data. The transition from (3) to (4) is observer design pattern with the builder notifying the its observer with the aggregated data.

The tricky piece is to trigger the data aggregation. It has to support service failure and aggregate partial analytics in case of non-responsive analytics services. Since I don't have knowledge of a suitable design pattern, let's improvise and implement an observable service that supports instance per call and that guarantees notifying its observer regardless of the result of the call to the external service. Then have created an instance of early described service for each analytics to be retrieved with the aggregator service instance observing it. Then the aggregator service instance has to have a stack of no-op of size n - 1 so the nth notification triggers the aggregation or has to support a state diagram and with each notification advance the state until the aggregation, with the side note that the aggregator service also has to support instance per call.

Now some hazardous advertising, maybe Spring Webflux is what you are searching for.