I have written a rest API that takes a request that is a list (size of this list is dynamic).

Now what my API does is, for each item in the list calls an external API and responds with the collection of all the responses.

Please refer the flow diagram below:

Now this process is time consuming and response time is too high.

Note:

1. This has to be a synchronous process.

2. We cannot implement pagination here.

3. Also we don't want to go for multithreading as it can be an overkill if the number of items is too less and if the number of items is too high it may eat up a lot of resources.

So is there something we can do to reduce this response time?

CodePudding user response：

For the solution for your problem I would recommend reactive microservices, that is, how to develop non-blocking synchronous REST APIs and asynchronous event-driven services.

Traditionally, as Java developers, we are used to implementing synchronous communication using blocking I/O, for example, a RESTful JSON API over HTTP. Using a blocking I/O means that a thread is allocated from the operating system for the length of the request. If the number of concurrent requests goes up, a server might run out of available threads in the operating system, causing problems ranging from longer response times to crashing servers. Using a microservice architecture typically makes this problem even worse, where typically a chain of cooperating microservices is used to serve a request. The more microservices involved in serving a request, the faster the available threads will be drained.

If a synchronous programming model is preferred, use reactive frameworks that can execute synchronous requests using non-blocking I/O, without allocating a thread while waiting for a response. This will make the microservices easier to scale in order to handle an increased workload.

CodePudding user response：

What is your use case here ? I see you have dynamic list to process and why it has to be synchronous and why cannot use pagination ? traditionally for such requirements pagination/HATEOAS kind of approach more suits. So trying to under stand your problem more.